What you will take away
- Low-code wins on internal tools with stable rules and shallow integration.
- The real cost of a platform shows up at seat count, not at licence price.
- Price the exit before you commit - it is the number that changes decisions.
The question is not which one is better
Low-code platforms are neither the shortcut their vendors describe nor the trap engineers assume. They are a trade: you give up control over the runtime, the data model and the upgrade path, and in exchange you get a working internal tool in days instead of months. Whether that trade is good depends entirely on what the tool has to do in three years.
The failure we see most often is not choosing low-code. It is choosing low-code for a workflow that turns out to be the core of the business, then spending two years working around the platform because migrating is now a project nobody wants to fund.
Where low-code reliably wins
- Internal admin tools used by a known, small set of staff.
- Forms, approvals and simple stateful workflows with rules that rarely change.
- Reporting layers on top of a database somebody else already owns.
- Anything you would otherwise build in a spreadsheet, where the real alternative is not custom software but no software.
- Prototypes that exist to test whether a process is worth automating at all.
The common thread is a bounded audience and shallow integration. When the tool talks to one database, has fewer than a hundred users and encodes rules a manager could describe in a paragraph, a platform is usually the cheaper answer over a five-year window.
Where it becomes a ceiling
Custom development earns its cost when any of four things is true: the workflow is a competitive differentiator, the integration surface is deep, the performance profile is unusual, or the compliance regime is strict enough that you need control over where data physically sits.
The signal to watch for is workaround density. When a team is writing custom scripts inside the platform to get around the platform, the abstraction has stopped paying for itself. At that point you are maintaining custom software with none of the tooling that makes custom software maintainable - no version control worth the name, no test suite, no local environment.
A platform is cheap until the day you need it to do something it was not designed for. Then it is the most expensive thing you own.
Costing it honestly
Compare the two options over five years, not at purchase. For the platform, price the licence at your projected seat count rather than today's, add the integration connectors that are billed separately, add the specialist contractor rate for that platform, and add the annual uplift written into the contract.
For the custom build, price the build, then add hosting, monitoring, security patching and roughly fifteen to twenty per cent of the build cost per year for maintenance. The comparison is usually much closer than either camp expects, and the tiebreaker is rarely money. It is how much the workflow is going to change.
Price the exit before you sign
Whatever you choose, answer this before committing: if we had to leave in two years, what would we get out? Ask for a full data export in an open format, check whether business logic is retrievable or locked inside a proprietary editor, and confirm who owns the customisations. A vendor that cannot answer those questions plainly has told you what you need to know.
A middle path works well more often than either extreme: run the process on a low-code platform first, learn what the rules actually are, and build custom only once the requirements have stopped moving. The platform then paid for itself as a discovery exercise, and the custom build starts from a specification that reflects reality rather than a workshop.
OrbixEdge Engineering
The engineers who build and run the systems we write about - platform, cloud and product teams shipping for clients in retail, health, logistics and fintech.
