Insights
Mostly yes for the first thousand users. Wrong data, the wrong person seeing a record and runaway cost break first. Here is what to test before launch. Mostly, for the first thousand users, yes: a modern host will not be overloaded by that few people.
Mostly, for the first thousand users, yes: a modern host will not be overloaded by that few people. What fails first is not speed. It is wrong data, the wrong person seeing a record, and a bill that grows faster than revenue. We would test those first, then load-test the two flows that make money. We have found no independent benchmark of AI-built apps against hand-built ones under load, so treat anyone quoting a precise breaking point as selling something. What follows is how to find your own.
The short answer
"Will it scale?" bundles four questions: will it stay correct, will it stay private, will it stay affordable, and will it stay fast. Early users punish the first three well before the fourth.
AI tools produce code that works for one user with a handful of rows. The gaps appear when there are many users, many rows and real money. Veracode's 2025 study of more than 100 models across 80 coding tasks found security flaws in 45% of the tasks, which is why access control belongs in the test plan alongside speed. We keep the full security checks in our vibe-coded app security checklist and the path to launch in Is your vibe-coded app production ready?. This page covers load, data, cost and testing only.
What breaks first
Listed from the most easily missed to the most costly to fix, with the test that finds each one.
| Symptom | Likely cause | Test that finds it | Size of fix |
|---|---|---|---|
| One user sees another's data | Row-level security off, or a policy that checks nothing | Sign in as two users in the same role and one in another; request each other's records by id | Small to medium |
| A list page slows as data grows | Missing index, or one query per row (N+1) | Seed realistic volume, then read the query plan | Small |
| A page loads everything at once | No pagination or limit | Seed 50,000 rows and open the page | Small |
| Intermittent "too many connections" or timeouts | Every request opens its own database connection | Ramp up concurrent users and watch errors | Small to medium |
| Emails sent twice, or a slow request that times out | Long work done inside the web request, no background job | Trigger the slow action twice quickly | Medium |
| Counts and balances drift | Two requests change the same row at once | Fire the same action from two sessions together | Medium |
| The AI bill outgrows revenue | Model calls with no per-user cap or caching | Cost model per active user (below) | Small to medium |
| Data lost, or no way back from a bad change | No tested backup, schema edited by hand | Restore into a blank project | Small |
| You learn about failures from customers | No error monitoring | Break something on purpose and see whether you are told | Small |
A few of these deserve a sentence.
Access first. Supabase's own guidance is that a table in an exposed schema without row-level security is readable and writable by any role with a grant on it, and that once it is on, nothing is returned until policies exist. A generated app can have only half of that done. The same page tells you to index the columns your policies filter on, because otherwise each read becomes a sequential scan, so the privacy fix and the speed fix meet in the same place.
Queries. In Postgres, EXPLAIN ANALYZE runs the query and shows estimated against actual rows and times for each step. A sequential scan on a table that holds thousands of rows, returning a few, is the signature of a missing index. With 20 rows in development you will never see it, which is why the seed data matters.
Connections. Serverless hosts start many short-lived instances, and each can open its own connection. Supabase documents a pooler for this and notes that idle clients still hold slots. Vercel's limits page shows a shared pool of 1,024 file descriptors across concurrent executions, which database connections count against, and recommends connection pooling. Duration limits matter too: a function that runs past its limit returns a 504, so work that takes minutes belongs in a background job.
Cost. Per-request compute is the smaller worry for most early apps. Calls to a language model can dominate, because each active user triggers them repeatedly.
A one-week test plan
Sized for a small team, in the order we would do it.
Day 1: seed and look. Load realistic volume: the number of rows you expect after a year, not a demo set. Open every list page and every search. For anything slow, run EXPLAIN ANALYZE on its query and add the index it points to.
Day 2: permissions per role. For each role (visitor, member, admin, and any customer account), write down what each may read and change. Then try the forbidden moves by hand, using another user's ids. Fix with row-level policies, not hidden buttons. A hidden button is not access control.
Day 3: load the two flows that make money. Pick sign-up and the core action, or checkout. k6 is a scriptable load tool with pass or fail thresholds; its own example fails a run if more than 1% of requests error or if the 95th-percentile response time reaches 200 ms. Pick limits that suit your product, ramp users up in stages, and watch for the point where errors or latency bend, not the average. Test against a staging copy, never production data.
Day 4: concurrency and repeats. Fire the same payment, booking or invite from two sessions at once. Submit forms twice. Retry a webhook. Look for duplicates, negative stock and drifting totals.
Day 5: cost per active user. Count what one active user does in a month: model calls and their size, emails, storage, reads. Multiply by the unit prices on your providers' pages, then by 100, 1,000 and 10,000 users, and compare with what each user pays you. If the line crosses, decide now: cap usage, cache, use a smaller model, or change the plan.
Day 6: restore drill. Back-ups are only real once restored. Supabase, for example, takes daily backups on its paid plans and recommends exporting your own on the entry plan; the project is offline during a restore, and storage files are not part of a database backup. Restore into a blank project, log in, and time it.
Day 7: be told when it breaks. Turn on error tracking and an uptime check, then break something on purpose. Google's SRE book names four signals worth watching: latency, traffic, errors and saturation. Even a small app benefits from an alert on the error rate.
Harden, refactor or rebuild
- Harden when the tests find mostly small fixes: indexes, policies, pagination, a pooler, a spend cap. Start here.
- Refactor parts when one area keeps failing: a billing flow with race conditions, or all data access scattered through the interface code. Replace that piece behind a clear boundary and leave the rest.
- Rebuild only when the data model is wrong (for example, one table holding several things, with no way to separate accounts) or when no one can explain how a change in one place affects another. Even then, keep the screens, the copy and what you learned about users.
If every test fails, that is still information about where to spend the first week of engineering, not proof the idea was a mistake.
Next step
If you want a second pair of eyes before launch, our prototype hardening review looks at an AI-built app the way this page does. Whichever way you go, run the plan above on a staging copy first and write down what you find.