When low-code is the right answer in an enterprise system

We should declare an interest. The company is called The Low Code Factory, and most of what we deliver is engineered software. That is not a contradiction so much as a summary of what fifteen years of building enterprise systems teaches you about the category: it is genuinely excellent within its envelope, and it is expensive to discover the boundary from the inside.

The debate is usually conducted badly. Vendors present low-code as a general solution to the cost of software. Engineers dismiss it as a way of accumulating technical debt with a drag-and-drop interface. Both positions are held with more confidence than the evidence supports, and neither is much use to somebody who has to make a decision about a specific system.

A more useful framing is that low-code platforms make a trade. They give you enormous leverage on a defined class of problem, in exchange for control that you will not miss until you need it and cannot get back when you do. The question is therefore never "is low-code good?" It is "does this problem sit inside the envelope, and will it still be inside the envelope in three years?"

Where low-code is genuinely the right answer

The envelope is real and it is larger than most engineers admit.

The problem is a form, a workflow, and a table. An enormous proportion of internal enterprise software is exactly this: capture some structured data, route it to some people for a decision, store the result, and report on it. A low-code platform will deliver that in a fraction of the time custom development takes, and the result will be perfectly adequate for as long as the problem stays that shape.

The requirements are volatile and the stakes are moderate. Where a process is still being figured out and will change monthly, the ability of a business analyst to adjust a form or a routing rule without a development cycle is worth a great deal. Custom software optimises for a stable target; low-code optimises for a moving one.

The alternative is a spreadsheet. This is the comparison that actually matters and it is almost never the one that gets made. A great deal of enterprise low-code does not replace custom software, because the custom software was never going to be built. It replaces an unversioned spreadsheet on a shared drive with no access control, no audit trail and one person who understands it. Against that baseline the platform's limitations are irrelevant.

The organization cannot support custom code. An enterprise with no engineering function, no deployment pipeline and no capacity to maintain a codebase will derive more value from a system on a platform its vendor maintains than from a superior bespoke application that decays because nobody can change it.

Where the envelope ends

The boundary is not usually where people expect. It is rarely about scale, and it is rarely about complexity in the abstract. It is about a small number of specific properties.

When correctness under failure is the requirement. If the system must guarantee that no record is lost when the network fails mid-batch, that a retry cannot duplicate a payment, that a partial completion can be resumed exactly where it stopped — these are properties you engineer, and they demand control over transactions, state and retry semantics that platforms abstract away precisely because most applications do not need them. When they are the requirement, the abstraction becomes the obstacle.

When the integration surface is the system. A platform's connectors are excellent for the systems it anticipated and awkward-to-impossible for the ones it did not. If the core of the work is reconciling three systems of record with incompatible models, fighting through a connector abstraction will cost more than writing the integration directly, and you will end up writing most of it directly anyway, inside a platform that makes it harder.

When the data model is genuinely complex. Platforms tend to assume tables of records. Where the domain is a graph, or temporal, or has versioning and effective-dating semantics that matter, encoding it inside the platform's model is an exercise in frustration whose outcome is a schema nobody can understand.

When the system will be the foundation for others. A system that other systems will build on needs a stable, documented interface and the ability to evolve without breaking its consumers. That is a poor fit for a platform whose upgrade cycle you do not control.

When performance at volume matters. Not "will it handle our load", which it usually will, but "can we do anything about it when it does not". The answer inside a platform is generally to raise a support ticket.

The costs that are real and the ones that are imagined

Two objections to low-code are raised constantly and only one of them is serious.

The unserious one is that the code is bad. It usually is not; it is simply not yours to inspect. What matters is not aesthetic but whether the system does what it must, and for a well-fitted problem it will.

The serious one is exit cost, and it is routinely underestimated by everybody involved. Business logic on a low-code platform is expressed in that platform's vocabulary. It cannot be lifted out. Leaving means rebuilding, and rebuilding means first reconstructing the rules from a visual model that was never documented, which is exactly the legacy modernization problem this article's sibling describes, arriving five years earlier than anybody expected.

This is the cost that should be priced at the decision point, and almost never is. It is not an argument against low-code. It is an argument for going in with an honest estimate of what leaving would cost, and for keeping the platform's footprint deliberately bounded so that estimate stays small.

A test that works

Four questions, asked in this order, settle most cases.

1. What must this system guarantee, and what happens if it fails to? If the answer involves money, safety, a regulator or a record that cannot be lost, be sceptical. The guarantees you need are the ones platforms abstract.
2. What is the realistic alternative? If it is a bespoke system this organization will actually build and maintain, compare them properly. If it is a spreadsheet, the comparison is over.
3. Will this still be the shape of the problem in three years? Not the requirements, which will change. The shape. A form-and-workflow problem tends to stay one. A system that is quietly becoming the operational backbone does not.
4. What would leaving cost, and can we bound it? If the honest answer is "we could not leave", that is a decision to take deliberately rather than discover.

The position that follows

Low-code is a tool, not a strategy. It is chosen per system, on the merits, against the constraints of the problem and the capabilities of the organization that will own it. Choosing it for one system implies nothing about the next, and an organization that has standardised on a platform as a matter of policy has stopped asking the question that matters.

The most common error is not choosing low-code where it does not fit. It is choosing it and then continuing to use it long after the problem has grown out of the envelope, because switching feels like an admission and because the exit cost has quietly compounded. The decision deserves revisiting on a schedule, honestly, and while it is still cheap.