Airtable, Zapier or Bubble: when no-code is enough, and when it isn't
By Michael James, Principal & Platform Lead at GO Build Labs
Before anyone pays a developer, someone usually asks whether a no-code tool would do the job. Airtable to hold the records, Zapier to pass information between apps, Bubble to put screens in front of it all. Often the honest answer is yes, at least for now. We say that on calls, and we've written about the times the right answer is to build nothing at all.
What they're good at
No-code tools are at their best while a process is still changing. You can try a new way of working on Tuesday and change it again on Wednesday without waiting on anyone. They're cheap to start, the person who understands the work can set them up, and for a small team handling a few hundred records they may be all you ever need.
The signs you've outgrown them
It's rarely one big failure. It's a list of small ones that keeps getting longer.
The bill grows with the business. Prices are set per user, per task or per unit of use, so a cost that looked small at the start rises with every hire and every order. Add up the yearly total across all the tools and compare it with what a system you own would cost to run.
You design around the limits. Caps on records, on automation runs or on how much logic a screen can hold start deciding how the business works, rather than the other way round.
The chain breaks quietly. A form copies to a table, which sets off an automation, which sets off another that emails someone. When one link fails without an error, records go missing and nobody notices for weeks. It's the same problem we described in why integrations always break, with less to catch it.
Access gets serious. Once customer records, money or compliance work is involved, you need control over who sees what and a record of who changed what. Most no-code setups give you less of that than you'd want.
One person holds it together. The whole system lives in the head of the employee who built it, which is the same risk as relying on a single developer.
Outgrowing them isn't a failure
A no-code setup that ran a process for two years is the best brief a developer can be handed. It shows which steps really matter, which fields people actually fill in, and where the awkward cases are. Rebuilding something that already works is far safer than building from a wish list.
If you're weighing it up, add three numbers: what the tools cost per year, the hours your team spends on workarounds, and the hours spent fixing automations that broke. If that total is creeping towards what a system you own would cost each month, it's worth the conversation. If it isn't, keep the tools and spend the money somewhere else.