When Airtable and Make stop being enough

A no-code system rarely fails outright. It gets slower, more fragile and more expensive a little at a time, until one day a large part of how your business runs sits inside something nobody wants to touch.

That point is real and you can recognise it when you get there. I think it's also further away than most people assume, and plenty of businesses that believe they've reached it have something else wrong.

Signs you've outgrown it

Runs timing out. A run that used to finish now doesn't. Every platform caps how long a single run can take and how much it can move. When your data grows past that cap, the fix is to split the job into smaller jobs. That works once or twice, and then you've got a chain.

Nobody can explain the whole chain. The scenarios have multiplied, each one sensible on its own, and "what happens to a record after the form is submitted" no longer has a short answer. The configuration is the only description of the system. There's no document, no history of what changed and when, and no way to compare what it did last month with what it does now.

One person who can fix it. That's the same problem from the staffing side, and it's usually the one that forces the decision. When they're away, you wait.

Managing limits, not work. Deleting history to stay under a record cap, or paying for a tier priced for a company several times your size, both mean the tool is setting the terms now.

Per-seat cost past what a build would cost. Multiply seats by platforms by twelve months, add the operation packs and paid lookups, and put a realistic number on the hours spent on workarounds. Compare that to a one-off build with a small running cost. There's a crossover, and it's worth working out properly.

Permissions that have to be enforced. Most no-code tools can hide a field or a view, but hiding it doesn't stop anyone getting to it. If a member of staff can still reach the data by exporting, by an API key, or by opening the base directly, then it's only hidden, not locked. That matters the moment one client's data sits beside another's.

You need a guarantee. Not having one costs real money. The Lead Data Platform case study is an example of this.

When to stay put

No-code is the correct answer for a great deal of work, and it's not a stepping stone to something better. If your system runs, one person can read it and understand the whole thing, and the cost is comfortable, stay.

Someone non-technical being able to add a field this afternoon is a real feature that custom software can't match, and I wouldn't call it a lesser version of software development.

More importantly, a mess inside Airtable is usually a modelling problem, not a platform problem. The Relational Archive System case study is an example, and the whole fix stayed in Airtable. What was holding them back was how their data was set up. Custom software would have cost a lot more and solved the same problem.

Before you price a build, price modelling what you have properly. It's the cheaper experiment and sometimes it's all you need.

What moving actually involves

It's rarely all-or-nothing. One part moves (normally the highest-volume piece, or the one that has to be correct every time) and everything else stays. Airtable often survives as the interface people use daily while the processing behind it moves somewhere it can be tested.

The work sits in two places. The first is deciding which system owns each piece of information, so two tools can never disagree about it without anyone noticing. The second is the migration, which will turn up problems you couldn't see inside the tool, like duplicates, inconsistent formats and records pointing at things that no longer exist. They're worth finding, but finding them takes longer than anyone expects.

What you gain and what you lose

You gain the ability to change something and know it still works before anyone depends on it. You gain a history of what changed, and permissions the system enforces. You usually gain speed too. The Lead Data Platform case study has an example of that too.

You lose immediacy, because nobody adds a field over lunch any more. You lose the library of ready-made connectors, and pay for the ones you need in build time. You pay a larger cost up front for a smaller one afterwards. And you need someone to call when it breaks, which is a relationship you want to set up before you need it.

A short test

Ask three questions. Can one person, who isn't the person who built it, explain what happens to a record from start to finish? If something ran wrong last Tuesday, can you find out what changed? Does anything in the system need to be guaranteed, not just checked?

Two noes and a yes is usually a build. Three noes is usually a modelling job. If all three answers are comfortable, you haven't outgrown it yet.