We build custom software, so treat what follows accordingly — but the honest position is that a large share of what businesses ask us for should not be built from scratch. An internal approval workflow, a data collection form feeding a report, a lightweight CRM for a team of fifteen: building these bespoke is often an expensive way to arrive somewhere a configured platform reaches in a fortnight. Recommending against a project is occasionally the right recommendation.
Low-code platforms are strongest where the problem is a well-trodden shape: forms, workflows, approvals, dashboards over structured data, and integrations between systems that already expose sensible APIs. In that territory they are not merely faster to build, they are faster to change, and the person changing them can be someone in the business rather than an engineer in a queue. That second property is frequently worth more than the first.
They weaken predictably. Anything with an unusual data model, high transaction volume, demanding latency, complex domain logic, or a user interface that must feel designed rather than assembled will meet the platform's edges. When it does, the escape hatch is custom code inside the platform — which is the worst of both, because you now have bespoke logic constrained by someone else's runtime, debugger and deployment model, maintained by people the market prices as scarce.
The costs that surprise people are not the licence fees at the start but the ones that scale. Per-user pricing is comfortable at twenty users and painful at four hundred. Consumption-based pricing on workflow runs behaves fine in a pilot and unpredictably at production volume. And the exit cost is real: what has been built is expressed in the platform's own representation, so migrating away is rebuilding, not porting. That is acceptable if you have decided it consciously and unacceptable if you discover it in year three.
The useful test is whether the thing you are building is the business or supports the business. Software that is your product, your differentiation, the thing customers pay for, should be built where you control it entirely. Software that runs an internal process nobody would ever pay for should be built the cheapest sustainable way, and that is frequently a configured platform. Organisations get into trouble by applying one philosophy to both.
A pragmatic pattern for companies with a mix is to run both deliberately: a low-code platform sanctioned for internal operations, with a clear boundary about what may be built there, and custom development for the product. What causes trouble is drift — an internal tool that quietly becomes customer-facing, or a proof of concept that reaches production without anyone deciding it should. Naming the boundary and reviewing it periodically prevents most of that.
