Spreadsheet to app
No-code is genuinely good. Here is exactly where it stops.
If you are searching for how to turn a spreadsheet into an app, you have probably already tried one of these tools. Airtable, Glide, Softr, Quickbase. They are good, they are cheap to start, and for a lot of jobs they are the correct answer.
So this page is not a sales pitch against them. It is the honest version: what they do well, the three specific points where people hit a wall, and what your options are once you are there.
Credit where it is due
What no-code genuinely gets right.
You can have something working this afternoon, without a developer, and change it yourself when you realise the first version was wrong. That last part matters more than anything else: the fastest way to learn what you actually need is to use a rough version for a fortnight.
For a small tool used by a few people, that is often the whole story. If Airtable is running a process for four people and costing forty dollars a month, you have already solved the problem and should spend the money elsewhere.
Wall one
Per seat, which is fine until everyone needs a seat.
No-code pricing is per editor or per user, which is cheap at four people and expensive at thirty. The moment the tool succeeds, everybody wants access, and the thing that cost forty dollars a month is now costing several hundred.
That is the same meter this entire site is about. It is not a criticism of Airtable specifically. It is what happens when the price of software is attached to how many people find it useful.
Wall two
The point where you are fighting the builder.
Every no-code platform has a complexity ceiling, and you find it the same way: a rule that should be simple takes four linked tables, three automations and a formula nobody else can read. You are still building, but you are building around the tool rather than with it.
The tell is when the person maintaining it starts saying “it is a bit fiddly but you just have to remember to”. Every business has one of those sentences. It is a load-bearing workaround, and it will outlive the person who invented it.
Wall three: making it talk to anything properly
Sooner or later it needs to know what accounting knows, or feed the system your clients see. No-code integrations are usually shallow: they can move rows, but they cannot enforce that two systems agree. That is where a real build starts earning its cost.
The scope
What gets built, and what we leave alone.
Stay on no-code when
- Fewer than about ten people need access
- The logic fits in your head and you could explain it in five minutes
- It does not need to agree with another system in real time
- Losing the whole thing would be annoying rather than serious
- You are still working out what you actually need. Build the rough version first, always
Move to a real build when
- Everybody needs access and the per-seat bill has become a real number
- Maintaining it requires knowing three undocumented tricks
- It has to integrate properly with accounting, payments or a customer-facing system
- A mistake in it would cost real money, or a regulator would want to see an audit trail
- The only person who understands it is one resignation away from leaving
And the honest middle. Sometimes the answer is to keep the no-code tool for the messy exploratory part and build the load-bearing part properly. That hybrid is more common than either extreme.
Common questions
Answered plainly.
Is Airtable good enough to run a business on?
For part of a business, often yes. It becomes the wrong tool when everyone needs a seat, when the logic starts fighting the builder, or when it has to agree with another system rather than just exchange rows with it.
How do I turn a spreadsheet into an app?
Start with a no-code tool. Genuinely. Build the rough version, use it for a fortnight, and find out what you actually need. Then, if you hit one of the three walls above, you will have a real specification rather than a wish list, and the build will be better and cheaper for it.
What does it cost to move from no-code to a custom build?
From $5,000, three to eight weeks. Coming from a working no-code version usually makes it cheaper, because the requirements have already been proven in practice rather than imagined in a meeting.
Can you migrate our Airtable data?
Yes, and the structure usually comes across cleanly because you have already done the thinking about what the entities are. That thinking is the expensive part of any build, and you have already paid for it.
Will you tell us to stay where we are?
Regularly. If a $40 a month tool is doing the job for four people, building something would be a waste of your money, and we would rather say so than take it.
Where to next
Show us the one that is getting fiddly.
The base with four linked tables and the trick nobody has written down. Twenty minutes and we will tell you honestly whether you have hit a wall or just need a tidier version of what you have.