Custom software versus low-code platforms
Low-code is right far more often than developers admit — and wrong in a specific, predictable way that arrives late.
Custom code
No ceiling, no per-user platform fee
Low-code platform
Days to build, non-engineers can maintain
Developers dismiss low-code reflexively and are wrong to. For internal tools, admin panels, approval workflows and form-driven processes, a low-code platform will get you a working system in days for a fraction of the cost, and an operations person can maintain it without waiting for an engineering sprint. That is a real win and we recommend it regularly.
It also has a ceiling, and the ceiling has a specific shape: it arrives late, after the tool has become load-bearing, and the migration off is a rebuild. Knowing where the ceiling is before you commit is most of the decision.
Where they actually differ.
| Dimension | Custom code | Low-code platform |
|---|---|---|
| Time to working tool | Weeks. | Days. A genuine and large advantage for internal tooling. |
| Who can maintain it | Developers. | Often an operations person, which removes an engineering dependency entirely. |
| Cost at low usage | Build cost dominates. | Cheaper by a wide margin. Not a close call. |
| Cost at high usage | Flat. Your infrastructure, no per-user fee. | Per-user or per-run pricing that compounds, sometimes sharply at tier boundaries. |
| Performance ceiling | Whatever you engineer it to be. | Real. Complex queries, large datasets and high concurrency degrade, often abruptly. |
| Complex logic | Arbitrary. Tested, versioned, reviewable. | Expressible up to a point, after which it becomes unmaintainable formula sprawl. |
| Customer-facing use | Full control of experience, performance and branding. | Usually constrained; rarely the right choice for a product customers pay for. |
| Exit cost | Standard code in your repository. Portable. | High. Logic lives in the platform's format; leaving means rebuilding. |
- It is customer-facing, or it is the product you charge for.
- The data volume or concurrency is beyond what the platform comfortably serves — check this with a load test, not an assumption.
- The business logic is genuinely complex and needs to be tested and versioned.
- It must integrate deeply with several systems, with reconciliation and audit requirements.
- It is load-bearing enough that platform pricing changes or a vendor pivot would be a serious problem.
- Internal tool, modest user count, form-and-workflow shaped. This describes a lot of software.
- You need it this week and the alternative is a spreadsheet.
- You want operations staff to change it without an engineering queue.
- You are validating whether the process is even right before investing in building it properly.
- The blast radius is small — if it broke, work would be annoying rather than stopped.
Our view
Use both, deliberately. Low-code for internal tools and process validation; custom for anything customer-facing, high-volume or load-bearing. The failure we get called about is not choosing low-code — it is a low-code tool that quietly became critical infrastructure with no plan for the day it stopped coping. Decide upfront which category a tool is in, and revisit when usage changes.
Follow-ups.
Do you work with low-code platforms?
We recommend them where they fit and we will tell you when a project does not need custom development at all. We do not specialise in building on them — if you want a Retool or Power Apps implementation, a specialist will do it faster and cheaper than we would.
Can you migrate us off a low-code tool that has outgrown itself?
Yes, and it is common work. The hard part is that business logic lives in the platform's own format, so it has to be extracted and reimplemented. We run the old and new systems in parallel until outputs reconcile before cutting over.
How do we know we are approaching the ceiling?
Three signals, usually in this order: the platform bill grows faster than usage; simple changes start breaking unrelated things; and someone starts maintaining a spreadsheet beside the tool. The third one means you are already past it.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.