Low-Code and No-Code: Where They Fit and Where They Break

Low-code platforms genuinely deliver on their promise for a specific class of application. The trouble starts when a tool that succeeded at an approval form is asked to run a core business process.

Where these platforms are the right answer

• Internal workflow and approval tools with tens to hundreds of users.
• Forms, request intake, and simple case management replacing shared spreadsheets.
• Departmental reporting and dashboards built by the people who need them.
• Prototypes used to validate a process before commissioning a real build.

Where teams hit the ceiling

• Complex conditional logic, which becomes unreadable and untestable in a visual builder.
• Volume — per-user or per-run pricing that was trivial at 50 users is punitive at 5,000.
• Integration depth beyond the platform's connectors, where you end up writing code anyway but in a constrained environment.
• Version control, code review, and automated testing, which most platforms support poorly or not at all.
• Customer-facing experiences where performance and design control matter.

The governance problem nobody plans for

The strength of these platforms — anyone can build — is also the risk. Within two years a typical organisation has dozens of applications, several of them business-critical, built by people who have since changed roles, with no documentation and no owner. Treat them as real systems: a register, a named owner, a criticality rating, and a rule about what may never be built this way.

Deciding between low-code and custom

• Will this still be running in three years? If yes, weigh platform costs and portability seriously.
• Is the logic likely to grow? Visual builders degrade sharply with complexity.
• Does it touch money, regulated data, or customers directly? Lean custom.
• What's the exit? Assume export gives you data, not logic — and price the rebuild into the decision.