Low-code: when to use it and when it is the wrong choice | Blog

What low-code solves well

The real gain of low-code is not typing less. It is eliminating the repetitive work that surrounds any enterprise application: registration screens, forms, role-based permissions, approval flows, reports, basic integration. It is work that has to exist, does not set anyone apart and takes weeks.

When that is the bulk of the system, low-code delivers in a fraction of the time, and the difference is not 20%: it is usually several times faster.

Where it is the right choice

Internal processes with forms and approvals: requests, records, administrative workflows.
Mid-sized systems with clear rules: where the complexity lies in the business rules, not in the engineering.
Replacing a critical spreadsheet: the one that became a system without ever being designed to be one.
Validating an idea: when you need to find out whether the process works before investing heavily.
Integration between existing systems: connecting what already exists, with rules in between.

Where it is the wrong choice

Being honest about the limit is what avoids a big bill later. Low-code tends to be the wrong choice when:

The product is the core of the business and will evolve for years with a dedicated team. What speeds things up at the start becomes a constraint as demands grow.
The requirement is extreme performance, high transaction volume or low, predictable latency.
The logic is inherently complex, with its own algorithm, rather than a sequence of business rules.
The user experience needs to be unique, with interactions that go beyond the standard form.

In these cases, the effort of bending the platform to do what it was not built for outweighs the effort of writing the code.

The question to ask first

More important than the list above: who owns the code, and does the system keep running without the platform?

There is a huge difference between a platform that generates real source code, in your stack and in your repository, and one that keeps the application alive only inside its own runtime. The second may be adequate, but the decision has to be a conscious one: you are accepting that the system depends on the vendor's existence.

That question defines the exit cost, and it almost never comes up in the sales demo.

Governance is not optional

The ease of building is the main risk of low-code. Before long, dozens of applications appear with no owner, no review and nobody knowing what data they touch. It is the same story as critical spreadsheets, with a better interface.

The minimum that prevents this: a defined owner for each application, review before going to production when sensitive data is involved, an inventory of what exists, and a lifecycle with a date to review or retire.

Low-code with AI changes the math

The recent combination has changed part of the calculation. With AI agents in the pipeline, low-code is no longer just visual assembly: you can describe the rule in natural language, generate the structure, the tests and the documentation together, and review what was produced.

This widens the ground on which it is the right choice, but it does not remove the code question or the need for governance. It only makes both more urgent, because the speed of creation has increased.

FAQ

What is low-code?

It is development in which much of the application is built through visual configuration instead of code written line by line. The gain is not in typing less, but in eliminating the repetitive work that surrounds any enterprise application: registration screens, forms, permissions, approvals, reports and basic integration.

When is low-code not the right choice?

When the product is the core of the business and will evolve for years with a dedicated team; when there is a requirement for extreme performance, high transaction volume or low, predictable latency; when the logic is inherently complex, with its own algorithm; and when the user experience needs to go beyond the standard form. In these cases, bending the platform costs more than writing the code.

Do I own the code generated with low-code?

It depends on the platform, and that is the most important question before choosing. There is a huge difference between a platform that generates real source code, in your stack and in your repository, and one that keeps the application alive only inside its own runtime. The second can work, but it means accepting that the system depends on the vendor's existence.

What is the main risk of low-code?

The ease of building. Before long, dozens of applications appear with no owner, no review and nobody knowing what data they touch, repeating the story of critical spreadsheets with a better interface. The minimum to prevent it: an owner per application, review before production when sensitive data is involved, an inventory and a defined lifecycle.

What changes when low-code has AI?

It stops being just visual assembly: you can describe the rule in natural language and generate the structure, the tests and the documentation together, with human review. This widens the ground where low-code is the right choice, but it does not remove the question of code ownership or the need for governance, and it makes both more urgent, because the speed of creation has increased.