You bought low-code because code was expensive. That price moved

When a company of two hundred people picks a new system, the same sentence turns up in every meeting. Building it ourselves would cost more.

That was true for years. It rested on one number, the cost of a developer day, and the number was easy to defend in front of anyone. A decision made in 2021 carries 2021 prices inside it, though, and most companies have not redone the sum once since.

Part of low-code's value was propped up by the price of code and part of it never was. Those two need separating, otherwise you end up judging a whole tool on the half of it that moved.

A product and an abstraction are different purchases

Buying an accounting system is buying a product. Somebody else runs it, tracks legislative changes, ships updates and carries the liability. What you bought is another company's attention on a problem you would rather not own.

An order approval flow built in Power Apps is a different animal. There you bought an abstraction. You designed the process, you run it, you decided every field and every exception, and the only thing you did not buy was the writing of code.

That distinction is the whole argument, because the price of code moved and the price of somebody else's attention did not. Recalculate the second category. Leave the first one alone.

Six signs that low-code has stopped paying off

There is no formula. There are symptoms, and three or more at once is the point where the numbers are worth adding up.

• A consultant day on the platform costs more than a developer day.
• Adding one field means waiting for a vendor roadmap.
• Data export is markedly worse than data import. That is usually deliberate.
• Somebody has a weekly routine that everyone calls "working around the system".
• The licence scales with users or records while the value delivered does not.
• The integration to your other system is a third-party connector with its own licence and its own vendor.

The last two are usually the largest in money and almost never land on the same internal cost sheet.

What not to rewrite

Anything where the vendor carries the law. Statutory reporting, payroll, e-invoicing, VAT returns. That is not software, it is a subscription to somebody who reads legislation and hits deadlines, and cheaper code does nothing for it because the expensive part was never code in the first place.

The same goes for anything that works, that nobody complains about, and that is not blocking real value. A system nobody suffers from is a budget line rather than a project, and budget lines get handled differently.

Why the price moved

None of this has to be taken on faith from tool vendors. It reads off what companies actually built.

On 10 September 2026 Shopify announced it had rebuilt the Shop app from React Native into Swift and Kotlin in twelve weeks, with Android cold start falling from 4433 ms to 2233 ms. We went through it in detail, including what had to be in place first. What an hour of agent work costs against an hour of developer time is a separate calculation we already published.

The short version is that the agents had something to copy and a fast way to check the result. That holds on our projects too. When the new version has an existing system to diff against line by line, the work looks nothing like greenfield. Moving a process out of spreadsheets into an internal portal always brings that reference along. So does leaving a system nobody maintains.

What you are really taking on

Here is where business cases mislead, even the honest ones.

A rewrite sells you ownership rather than code. Somebody carries the pager, and somebody has to know in three years why that exception is sitting there. Cheaper code makes year one cheaper. Year ten costs what it always did.

So the decision belongs in a five-year budget and not in a delivery quote. Licences, consultants, connectors and the hours people spend working around the thing on one side. Build, run, upgrades and one person who understands it on the other. A narrow gap is an argument for staying put, because narrow does not pay for a migration.

A clear gap is not an argument for starting with the biggest system either. Take one layer that has a reference and a check, rewrite that, and measure whether the estimate held. It is why we open software modernization with analysis and a single bounded stage. The first rewrite is the only reliable source of numbers for the second.

One concrete step to finish on. Pull the invoices for licences, consultants and connectors from the last three years and add them up. That total is half the decision, and hardly anyone has it to hand.