No-code tools solved a real problem: most small-business workflows are simple enough that paying a developer to write bespoke code for them was always overkill. The mistake now runs the other way — treating no-code as free of tradeoffs, and reaching for a custom build reflexively once a workflow gets slightly more complicated than a single Zap.
Quick answer: No-code (Zapier, Make, Airtable, Bubble and similar) is the right choice for most small-business automation and internal tools — it's fast, cheap upfront, and needs no developer to maintain. It stops being right once volume gets genuinely high, the workflow doesn't map onto the tool's building blocks, access control matters, or the ongoing per-task subscription cost starts to rival what a one-off custom build would have cost. Prototype in no-code first in almost every case; move to custom only once you can point to a specific way no-code is actually failing.
What no-code is actually good at
- Connecting existing tools. Pushing a new lead from a web form into a CRM, or a paid invoice into an accounting system — no-code's original and strongest use case.
- Simple, repeatable internal workflows. Approval chains, basic databases with a form front-end, scheduled reminders — the same shape of job that made spreadsheets useful, with less manual copying.
- Proving a process before paying to build it properly. A no-code prototype run for a month tells you honestly whether a workflow is real and repeatable, for a fraction of a custom build's cost.
- Low-volume, low-stakes jobs. If something happens a few dozen times a month and nothing sensitive is involved, the overhead of custom code rarely pays for itself.
Where no-code genuinely breaks down
Answer: At real transaction volume, with workflows that don't fit the tool's model, wherever access control matters, or once ongoing per-task costs start rivalling a custom build's price.
The specific failure points:
- Volume. Most no-code platforms price per task or per run. A workflow that processes a few hundred items a month is cheap; the same workflow at ten thousand a month can cost more per year than a custom build would have, one-off.
- Non-standard logic. No-code tools model workflows as a sequence of triggers and actions. Genuinely branching, stateful, or conditional logic gets bolted together with workarounds that are fragile and hard for anyone else to follow later.
- Access control. Most no-code platforms have limited or no concept of "this person can see records A and B, that person only C" — a real gap once sensitive customer or financial data is involved.
- Reliability at the edges. A chain of five or six connected steps across different platforms has more failure points than a single piece of custom code, and when it breaks, debugging means reading someone else's automation rather than a stack trace.
None of these mean no-code was the wrong starting point. They mean the job has grown past what it was ever meant to hold.
The cost comparison, honestly
| No-code | Custom software | |
|---|---|---|
| Upfront cost | £0-£500 setup, mostly time | £3k-£40k+ depending on scope |
| Ongoing cost | £20-£500+/month, scales with usage | Hosting only, typically £20-£100/month |
| Speed to first version | Days | Weeks to months |
| Who can maintain it | Often a non-developer | Needs a developer |
| Best at | Simple, low-volume, standard workflows | High volume, custom logic, sensitive data, long-term cost control |
The crossover point — where a custom build's higher upfront cost is repaid by lower ongoing cost — usually lands somewhere between one and three years of real usage at scale. Below that, no-code almost always wins on total cost, not just speed.
A worked example: an events business outgrows Zapier
A 6-person events company automated booking confirmations with a Zapier chain: a form submission creates a record in Airtable, triggers a confirmation email, and pings a Slack channel. It worked well for a year at roughly 30 bookings a month.
Step 1 — is volume still low? No. Bookings grew to around 400 a month across three event types, each needing slightly different confirmation logic Zapier's linear steps struggle to branch on cleanly.
Step 2 — is the ongoing cost still small? Not really. The Zapier plan needed to jump a tier for task volume, landing around £70/month, and a second tool was added to handle the branching logic, adding another £40/month — nearly £1,300/year for something now held together by two platforms and a handful of workarounds.
Step 3 — does the workflow now need real branching, access control, or reliability the chain can't give it? Yes — different event types need genuinely different confirmation and reminder logic, and a missed confirmation costs a no-show, which is a real revenue hit, not a minor annoyance.
The maths: the two-tool no-code setup runs ~£1,300/year indefinitely, with an admin quietly working around its limits most weeks. A custom booking-confirmation flow — one clean piece of code replacing both tools and handling the branching properly — runs roughly £4k-£6k once, then £20-£40/month to host. It pays for itself against the no-code subscription within 3-4 years, and removes the workaround entirely well before that.
Verdict: this one's a genuine custom-build case, but only because volume and branching logic both grew past what the no-code chain was built to hold — not because no-code was ever the wrong choice to start with.
When should you NOT move to custom software?
- The no-code version still works. If nothing's actually broken and the cost is manageable, "custom would be cleaner" isn't a reason to spend money — it's aesthetic preference wearing a business case.
- Volume is still low. A workflow running a few hundred tasks a month rarely justifies a custom build purely on cost grounds, even if it feels inelegant.
- You haven't identified the specific failure. "It feels held together with tape" isn't a spec. Know exactly which limit — volume, logic, access control, or cost — you've hit before commissioning anything.
- The team can still maintain it themselves. Once a workflow needs a developer to touch it, you've taken on an ongoing dependency. Only do that once the no-code version is genuinely costing more than that dependency is worth.
How to actually decide
Start every workflow in no-code, full stop — even one you strongly suspect will eventually need custom code. Run it for real. Move to a custom build only once you can point to one of the four specific failure points above, with numbers, not a feeling that the Zapier chain looks messy. For the wider decision between building something at all versus buying a ready-made tool first, see our framework for choosing your first AI project — the same buy-before-build logic applies whether or not AI is involved.
If a no-code workflow has grown past what it should still be handling, our AI System Audit is a fixed-scope review of what's actually worth rebuilding versus what's fine to leave alone.