No-Code vs Custom Development: An Honest UK Guide to the Middle Ground

Quick answer

No-code platforms (Airtable, Bubble, Glide, Webflow, Zapier and kin) have permanently changed the build-vs-buy question: workflows that cost £15,000 of development in 2019 are now a fortnight of configuration at £50/month. For most internal tools, that trade is simply correct. But no-code has four real ceilings (complexity, volume economics, integration depth, and ownership), and businesses that hit them after two years of building on a platform face a migration nobody budgets for. The honest strategy: no-code first for validation and internal tools, custom when a ceiling is genuinely reached, and architecture decisions along the way that keep the exit affordable.

Where no-code genuinely wins

• Internal tools with standard shapes: registers, approval flows, trackers, dashboards: the natural next rung after outgrowing spreadsheets, at £20 to £100/month instead of £10,000.
• Validation before investment: a Bubble or Glide prototype in front of real users in a fortnight answers “does anyone want this?” for hundreds of pounds: the cheapest possible way to be wrong. If the answer is yes, the custom build inherits proven requirements.
• Glue between real systems: Zapier/Make bridging forms, sheets, accounting and email is automation’s workhorse tier, and often permanent.
• Speed as strategy: when the opportunity has a window (a contract, a season), shipping something workable this month beats shipping something perfect in six.

The four ceilings (and how they announce themselves)

None of these ceilings mean no-code was the wrong choice. Usually it bought years of cheap capability and a perfectly specified brief for what comes next. They mean the next chapter is different, which is exactly the decision structure in custom vs off-the-shelf, one level up.

The hybrid path most businesses actually take

The winning pattern isn’t either/or: validate in no-code → run the stable version while volume grows → move the core to custom when a ceiling bites, keeping no-code at the edges (admin panels, internal dashboards and one-off automations are often better left in Airtable/Zapier indefinitely). Two habits keep the eventual migration affordable: keep your data model clean and exportable from day one (name fields properly, avoid platform-magic features for critical records), and route integrations through standard formats where possible rather than platform-proprietary connectors. Migrations hurt in proportion to how deeply the platform’s cleverness got embedded in the business logic.

The costs side by side (UK 2026)

No-code: £0 to £100/month single-tool tiers; £100 to £500/month for a stacked setup (builder + automations + database) at modest scale, plus configuration time, which is real but non-technical. Custom: £5,000 to £15,000 MVPs, £15,000 to £75,000 production systems, plus 15 to 25%/year upkeep. The comparison that matters is the three-year total at your projected scale, not today’s: per-seat pricing is the line that bends. When the arithmetic starts flipping, that’s the conversation our custom software service is built for: taking a no-code system that proved the workflow and rebuilding its core on foundations you own.

A worked example: the booking system that moved

A pattern we see repeatedly, told as one story. A mobile valeting firm builds its booking flow in no-code: a form tool feeding Airtable, Zapier sending confirmations, £61/month all-in. It works: bookings triple over two years. Then the ceilings arrive together: three vans mean conflict-checking logic the visual builder handles badly (double-bookings start costing real money), task volume pushes Zapier to £180/month, and the owner wants customers to reschedule themselves, which the stack can’t do cleanly. Total platform spend by now: ~£2,900 over two years, money well spent, because it validated the business and wrote the specification for what came next. The custom rebuild (a booking engine with live availability, self-service rescheduling and SMS) costs £9,500, keeps Airtable as the back-office view the staff already like (the hybrid pattern), and carries ~£1,800/year maintenance. The arithmetic: the new system’s platform costs drop to near zero, the double-booking losses stop, and rescheduling self-service saves roughly an admin-hour a day. Payback lands inside eighteen months, and the two years of no-code history meant the £9,500 build specified exactly the right thing, which is the part first-time custom buyers usually get wrong. The sequence, not either tool alone, was the strategy.

A three-year worksheet, not a monthly price

Almost every bad decision in this area comes from comparing a monthly subscription against a one-off quote. Put both on the same three-year footing and the picture changes. The worked example below assumes a field-services business of five office users growing to twenty-two, running a builder, an automation tool and a database; figures are illustrative but built from the way these platforms actually price.

On these numbers no-code still wins over three years, which is the point most agency comparisons bury. It only loses at year four or five, at higher headcount, or if configuration time is being done by an expensive person. Two adjustments flip it much sooner: unlimited-seat needs (giving fifty subcontractors read access is free in custom software and ruinous per-seat), and any workload where the platform charges per record or per task rather than per user. Run your own version of this table with your projected headcount before anyone writes a quote, and be honest about the configuration hours: they are the line businesses always set to zero and always spend.

Five workloads no-code handles badly

• Granular permissions. “This subcontractor sees only their own jobs, and only the labour cost, not the margin” is trivial in code and a maze of workarounds in most builders. Businesses routinely solve it by giving people access they should not have.
• Document generation at volume. Branded, paginated PDFs (quotes, certificates, statements) usually mean a third add-on with its own per-document pricing, and templates that break when a field name changes.
• Offline or poor-signal use. Engineers in plant rooms and basements need an app that queues data locally. Most no-code front ends assume connectivity and lose the form.
• Time-critical scheduling. Automation platforms poll on intervals and queue under load; anything where a five-minute delay causes a double-booking or a missed SLA needs deterministic execution.
• Audit trails you can defend. Regulated work, disputes and insurance claims need an immutable record of who changed what and when. Version history in a spreadsheet-style database is not the same thing.

None of these are exotic. They are the ordinary requirements that turn a happy internal tool into a system that needs building properly, the point where the conversation moves to a scoped web application with a fixed price and a defined feature set, rather than another add-on subscription.

Where your data actually lives, and why UK GDPR makes it your problem

Configuring a platform does not outsource your legal position. If you decide what customer data is collected and why, you are the controller and the platform is your processor, which means you need a written processor agreement covering the Article 28 requirements. Most vendors publish a data processing addendum, and it is on you to accept and keep a copy. Three practical checks follow. First, where is it hosted? Many popular tools default to US regions; UK-to-US transfers need an appropriate mechanism such as the UK addendum to the standard clauses, and your privacy notice should reflect it. Second, can you satisfy a subject access or erasure request? That means finding every copy of a person’s data, including the ones sitting in automation logs and archived table views, which is where most no-code stacks quietly fail. Third, who has access? Shared logins and “everyone is an editor” defaults are the most common security finding in these systems. The broader obligations are set out in our guide to what GDPR-compliant software actually requires, and they apply identically whether you built the thing or dragged it together.

The habits that make the eventual migration cheap

1. Never let the platform’s internal record ID be your business reference. Give jobs, customers and invoices your own sequential reference from day one; migrations that have to invent identifiers afterwards are the ones that duplicate records.
2. Keep files out of the platform. Store photos, signed documents and drawings in ordinary cloud storage and link to them. Attachments held inside a database tool export as expiring URLs, and businesses discover this the week they leave.
3. Write the rules down in English. A migration is priced from a specification; if the only description of your pricing logic is thirty automation steps someone built in 2024, a developer has to reverse-engineer it at your expense. Maintaining a plain-language spec as you go turns a discovery phase into a read, the discipline covered in how to brief a software project.
4. Do not rebuild what a category tool already does well. Sales pipelines, email sequences and contact management are solved products; homegrown versions in a database tool are the classic case of expensive configuration replacing a £30/month subscription, as the comparison in our honest guide to CRMs lays out.
5. Take your own backups. A scheduled export to storage you control, weekly, is fifteen minutes of setup and the only thing standing between you and a billing dispute that locks the account.

Sources & Further Reading

• Airtable Pricing, Airtable
• Bubble Pricing, Bubble
• Zapier Pricing, Zapier