Where low-code genuinely wins
Low-code is not a lesser choice by default. For an approval process, a site inspection form, an asset register or a short-lived campaign tool, a configured platform can deliver useful software in days rather than months.
It also moves some of the maintenance burden to the vendor. Updates, hosting and basic security are handled for you, and a non-developer can often make small changes without a release cycle. When those advantages match the problem, choosing custom software can be a vanity decision.
- The workflow is well understood and unlikely to change much
- The number of users, records and integrations is modest
- The tool supports internal operations rather than customer experience
- The platform is not expected to become a product you sell
Where the platform starts to cost more
Platform limits rarely announce themselves. They accumulate. A simple form gains a second approval step, then a third. A report needs data from another system. A customer-facing portal needs to look and behave like the brand rather than the template.
Each of those changes is possible, but the workarounds multiply: duplicate data, brittle automations, per-user licensing that grows with adoption, and interfaces that cannot be made accessible or fast enough. The licence is rarely the expensive part; the friction and workarounds around it are.
- Workarounds and duplicate sources of truth
- Per-user or per-record costs that scale with success
- Limited control over performance, accessibility and interface quality
- Vendor roadmap and pricing changes you do not control
- Difficult export or exit if the platform stops fitting
The total cost of ownership argument
A low-code build often wins on year one cost. A custom build often wins on year three, but only if the workflow is important enough to justify the investment. If the process changes every six months, a platform that lets operations adapt it may still be cheaper overall.
The useful comparison is not licence versus development days. It is the cost of building, changing, integrating, supporting and eventually replacing each option over the period the workflow will exist.
- How often the workflow is expected to change
- Who will make those changes and at what cost
- Which integrations are essential versus nice to have
- What happens to data and access if the platform is replaced
Questions that usually settle the decision
Start with the role of the workflow, not the technology. If it is how the business earns money, serves customers or meets a regulatory obligation, it probably deserves software designed around it. If it is an internal convenience that could be replaced without much disruption, a platform is often sufficient.
The second question is change. Custom software is a commitment to owning a product: design, engineering, hosting, support and a roadmap. That is worthwhile when the product is important and expected to evolve. It is a burden when the problem was always going to be temporary.
- Would a week of downtime stop the business?
- Does the interface need to meet a brand, accessibility or performance standard?
- Are there integrations the platform cannot support cleanly?
- Will this still be running in three to five years?
- Do we want to own the roadmap, or follow a vendor's?
A hybrid route is often the honest answer
The choice is not always binary. Many sensible architectures keep a low-code or SaaS platform for the parts it handles well — workflow automation, simple data collection, an established CRM — and build the specific operational or customer-facing layer that the platform cannot do properly.
That keeps the first release cheap where cheapness is safe, and puts engineering effort where it changes the experience or protects the business. The important thing is to make the boundary explicit so data ownership does not drift into ambiguity later.
- Keep the platform for stable, internal, low-differentiation work
- Build the customer experience and core operational logic
- Integrate through a clear API rather than copying data between tools
- Document which system owns each record from the start