No-code got you to 100 users. Here is the bill for the next 1,000.

If you built your SaaS without developers and a hundred people now use it, you made a good decision. You found out whether anyone wanted the thing for the price of a few subscriptions and your evenings, which is cheaper than any agency would have done it. Nothing in this article argues otherwise.

What the no-code guides leave out is the second half. Most of what you search for on the subject is freelancer gigs, tool vendors and posts old enough to recommend platforms that no longer exist. None of them tell you what happens between a hundred users and a thousand, because none of them are around for it. I am, usually when a founder calls to say the app has started doing something nobody can explain.

So this is the bill, itemised: what growth costs on the platform you are on, how to tell which line you are already paying, what you can take with you if you leave, and what a rebuild actually takes, in weeks and money.

What no-code got right

It is worth being precise about this, because it tells you what to keep. No-code is excellent at the first version of a workflow: a form, a list, a few rules, an email when something changes. It lets the person who understands the problem build the solution directly, with nobody translating. And it makes changing your mind almost free, which is exactly what you need while you are still finding out what the product is.

Those strengths all belong to the search phase. The bill starts arriving when the search is over and the job becomes running the same workflow, reliably, for ten times as many people.

The bill arrives in four currencies

You rarely pay all four at once. The useful exercise is working out which one you are paying now and which one is next.

1. Pricing that meters your success

Almost every no-code platform prices on a unit that grows with usage, not with revenue. That is fair, and it is also why the bill grows faster than you expect: the unit counts work, and a thousand users do a lot more than ten times the work of a hundred, because they generate more records, more automations fire per record, and every list gets longer to search.

workload units on Bubble's Team plan$549 a month billed annually. Every search, workflow and API call spends them

500K

records per base on Airtable Team125,000 on Business. The cap counts every table in the base together

50,000

per action, per run, on ZapierA Zap with four actions spends four tasks every time it fires

1 task

Take a modest example. A product where each customer account logs about fifty records a month, stored in Airtable, with a four-step Zap that fires on each new record. At a hundred accounts that is 5,000 records and 20,000 tasks a month: comfortable, and the Team plan's record cap is ten months away. At a thousand accounts it is 50,000 records and 200,000 tasks a month. You hit the Team cap in the first month and the Business cap before the end of the third, and the automation bill is now a line you discuss with your accountant.

None of this is hidden. It is on every pricing page. What catches people is that the plan that fit at a hundred users was chosen when the unit was abstract, and the growth that breaks it is the growth you were hoping for.

2. Ceilings you find by hitting them

The second currency is time, mostly your users'. No-code platforms are built to make the common case easy, and they get there by deciding things for you: how data is queried, when background work runs, how many requests per second an integration may make. Airtable's API, for example, allows five requests per second per base, which is plenty for a back office and nowhere near enough for a product with a thousand people clicking.

The symptoms are consistent across platforms:

• Pages that get slower as lists get longer. A search that filtered a few hundred rows instantly now filters a hundred thousand, and you cannot add an index because you never see the database.
• Background work that queues. Scheduled workflows and exports share capacity, so a busy hour delays the reminder emails, and a busy day delays the billing run.
• Logic nobody can test. The rules of the business live in dozens of visual workflows. There is no test suite, so every change is tested by customers, and after the third incident people stop making changes.
• Glue that fails quietly. A Zap that errored at 2am does not page anyone. You find out when a customer asks why their invoice never arrived.

That third one is the real ceiling. Platforms get faster every year. A product that nobody dares change does not.

3. Security nobody reviewed

At a hundred users, nobody is looking. At a thousand, someone is, and the first one is often a prospect's security team with a questionnaire that asks how tenant data is isolated, who can access production, and where the audit log is.

The risk is not that no-code platforms are insecure. It is that their access rules are configured by hand, per data type or per table, and nothing forces you to configure them. Bubble's privacy rules are opt-in for each data type. A Supabase table without row level security is readable by anyone holding the public key that ships in your frontend. In 2025 a researcher scanned 1,645 apps from Lovable's public showcase and found about 170 whose databases could be read, and in some cases written, by anyone, logged in or not. It was logged as CVE-2025-48757 with a critical score. Lovable disputed that it was their bug, and they have a point: each app's owner was responsible for its rules. That is exactly the problem. The owner was usually a founder who did not know the rules existed.

Multi-tenancy is the usual weak spot. In most no-code builds a company field on every record, plus a constraint on every search, is the whole tenancy model. Every search you forget to constrain is a leak, and nobody will ever list them for you. The isolation boundaries in a multi-tenant SaaS are the same whether a developer or a visual editor draws them; the difference is whether anything checks.

4. The rebuild that gets dearer every month

The last currency is the one that compounds. Every month on the platform adds rows to migrate, integrations to replace, workflows nobody wrote down, and user habits the new version has to preserve or explain. None of that is wasted, because it is the product. But a rebuild at three hundred users with one integration is a different project from a rebuild at two thousand users with nine, and the second one has customers who will notice every difference.

This is not an argument for rebuilding early. It is an argument for deciding deliberately, rather than having the decision made for you by an outage, a security incident or a plan you cannot afford.

What you can take with you

What leaving costs depends almost entirely on what kind of tool you built on, because they differ completely in what they let you keep.

The last row is the interesting one. AI app builders give you real code, which is a genuine advantage over the platforms above it. It is also code nobody has read, and the review sometimes concludes that the frontend is fine and the data layer needs replacing, or that the whole thing is sound once the access rules are fixed. You only find out by reading it, and what the move from Lovable to production involves has its own article.

The rebuild, in weeks and money

A rebuild from no-code is not the same project as building from scratch. You skip most of the expensive discovery, because a working app with real users is the best specification anyone will ever hand a developer. You pay instead for the data, the integrations and the cutover. For a typical product with one core workflow, it runs like this:

Eight to fourteen weeks. That is close to the seven to nine weeks a lean MVP takes from scratch and well under the twelve to twenty for a production platform, because the scope is proven: you are not paying anybody to build features that turn out not to matter.

Eight to fourteen weeks is 320 to 560 hours. At 2026 market rates that is roughly $8,000 to $14,000 with a senior developer in South Asia, $13,000 to $39,000 in Eastern Europe, and $26,000 to $112,000 through an agency in North America or Western Europe. As with any build, most of that spread is geography rather than scope, and the same weeks priced in any of those markets describe the same project.

The migration costs nobody quotes

These are the lines that turn a ten-week rebuild into a twelve-week one, and every one of them is cheaper if you know about it in advance:

• Passwords. Most platforms will not give you password hashes, so every user resets their password at cutover. Plan the email, the support load and the day you send it. Supabase is the exception: you own the project, so the hashes come with you.
• Billing ownership. If the Stripe account is in your name, subscriptions, cards and customer IDs carry over untouched. If payments ran through a plugin or a platform's own account, moving every subscriber is a project of its own.
• URLs. Every link in an email, a bookmark or a search result points at the old structure. Map them and redirect them, or lose the traffic.
• Files. Uploads live in the platform's storage, behind its URLs. They need copying, and every record that points at one needs updating.
• Email reputation. Transactional email sent through the platform's servers leaves its reputation behind. Warm up your own sending domain before cutover, not on the day.
• Integrations that call you. Anything sending webhooks to the old app needs repointing, and some partners take weeks to do it.

Stay, harden or rebuild

Make the exit cheap, starting this month

Whether you rebuild next quarter or never, these cost almost nothing now and take weeks off any future move:

1. 1Export all your data every month and open the export to check it is complete. A backup you have never opened is a hope.
2. 2Own the domain, the Stripe account and the email sending domain in your own name, not the platform's or a freelancer's.
3. 3Write down every automation: what triggers it, what it does, and what breaks if it stops. This document becomes the specification.
4. 4Run the two-minute tenant test above after every change to access rules.
5. 5Keep a stable ID on every record that is yours, not the platform's, so rows can be matched after migration.
6. 6Note the five things customers complain about most. They tell a rebuild what to fix rather than copy.

No-code was not the mistake. The mistake is letting the platform decide when you leave, because it will choose the worst possible week.

If your no-code or AI-built app is starting to strain, I will read it, export the data, and come back with a written answer: keep it, harden it, or rebuild it, what each costs in weeks, and what to do first. The review is a fixed fee, and you owe nothing further if the answer is to stay. Get a no-code rescue assessment.