What happens to my AI-built app when ten thousand users show up?
Usually the database slows down first, then the bill climbs, then a few people see errors or someone else's data. An app built with an AI coding tool was written to work for one person clicking through it. Nothing in it was written for ten thousand people at once, because nobody asked for that.
Most of the first problems are cheap to find before they happen. You can load-test a copy of your app in an afternoon, put a spending cap on every service, and check the handful of places where a slow query or a public file bucket turns traffic into a bill. The rest you deal with when you have real numbers.
If you have a few hundred users today and no launch planned, you probably do not need help yet. Do the checks below and keep building.
In founders’ words
“I have used 25 GB in a few days. This is impossible." Later, with the cause found: "I managed to create a public storage bucket for the receipt images. Of course a bot found it.”
“When one of my projects passed 50k users, a small migration mistake almost wiped half the data.”
“I built downrightnow.app in Lovable, stress-tested it before launch, and found that Lovable was not the real bottleneck. Bad architecture was.”
What breaks first, in order
- The database. AI tools write queries that fetch a whole table and filter in the app. Fine at fifty rows, slow at fifty thousand. Missing indexes make it worse. An index is the database's lookup list for a column; without one, every search reads the whole table.
- Connections. Each visitor opens a connection to the database, which allows a fixed number at once. Past that, new visitors get an error. A connection pooler shares them out, and on most providers it is one setting.
- The AI calls. If your product calls a model on every request, the provider's rate limit arrives before your server's does, and the bill arrives after.
- The bill. Database egress, file storage, serverless functions and model calls are priced by use. A spike costs money, and a bot hitting a public bucket costs money with no users at all.
- Things that only mostly worked. Two signups in the same second, a payment webhook that arrives twice, a form submitted twice. Rare at ten users, daily at ten thousand.
How to find out before it happens
Make a copy of the app with a copy of the database, so nothing you do touches real customers. Ask your coding agent to write a load test with a free tool such as k6 or Artillery: a script that pretends to be five hundred people doing the three most common things in your product. Run it while you watch the database dashboard. Note the number at which pages slow past a few seconds or errors start. That number is what you plan around, and it is usually smaller than you guessed.
Then ask the agent two questions in writing: which queries have no index on the column they filter by, and where does the code load a whole table to find one row. Fix those first. They are the cheapest fixes with the largest effect.
Load testing is not a one-off. Repeat it after any change to the data model.
Caps and alerts you can set today
- A spending cap or billing alert on every service you pay by use: the database, the host, the AI provider, file storage. Each takes a few minutes in the billing settings.
- A limit on how often one user can call the AI features, so a script or a stuck page cannot run up the bill.
- Every file bucket private unless the files are meant to be public. Check the storage settings, not the code.
- Error reporting that reaches your phone. Free tiers exist. Set it up before launch, not after.
- An uptime check every few minutes from outside your app, so you hear about an outage before a customer tells you.
None of this needs a developer. It needs an hour and the dashboards you already have.
What ten thousand users does not change
You do not need to leave your host, move to a bigger platform, or rebuild for scale before you have the numbers. Most products at this size run on one managed database and one managed host. The structure is only wrong where the load test says it is wrong.
Rewriting before launch is the most expensive way to prepare for traffic that may not come. Fix what the test shows, cap what can cost money, and watch what happens. If the launch goes well, you will have real numbers to plan the next step from. If it does not, you spent an afternoon instead of a month.
When it is worth bringing someone in
Bring someone in when the load test falls over at a number smaller than your launch plan, when paying customers are already on the app and you cannot tell what is finished, or when the fix the coding agent proposes is a rewrite. Those are the cases where structure, not a setting, is the problem, and where a second fix tends to undo the first.
We run our own AI products in production and go through this before our own launches. On a call we can tell you, from your numbers, whether you are at that point. Often you are not.
| What you see | Usual cause | Check it yourself |
|---|---|---|
| Pages slow down as data grows | A query loads the whole table, or filters on a column with no index | Open the slow-query list in the database dashboard. Ask the agent to add an index for every column you filter on. |
| Errors at busy moments | Database connection limit reached | Turn on the connection pooler and point the app at its address. |
| "Rate limit" errors from the AI feature | Provider limit per minute | Limit calls per user, queue the rest, and ask the provider for a higher limit before launch. |
| Bill jumps with no new users | Public bucket, bot traffic, or a retry loop | Make buckets private, set spending caps, and look at function logs for the same call repeating. |
| One user sees another user's data | Missing row-level rules, exposed under load | Log in as two accounts and try to open each other's records. Turn on row level security on every table. |
Questions
Do I need to move off Lovable, Replit or Vercel to handle ten thousand users?
Usually not. The host is rarely the first thing to break. Fix the queries, turn on the connection pooler and set the caps, then load-test again. Move only if the test still fails and the dashboard shows the host, not the database, as the limit.
How many users can one Supabase or Neon database handle?
It depends on what each page asks the database to do, far more than on how many users you have. A well-indexed app on a small plan handles more than a badly indexed app on a large one. Your dashboard shows the connection limit and CPU for your plan; the load test shows where you are against them.
What does a load test cost?
The tools are free, and the agent can write the script. The cost is an afternoon and a copy of your database to run it against. Never run it against the live database.
Will the AI calls get expensive?
They grow with use. Set a monthly cap at the provider, limit calls per user, cache answers that repeat, and use a cheaper model for the cheap steps. Watch the provider's usage page during the test.
Should I rewrite the app before launch to be safe?
No. Fix what the test shows, cap what can cost money, and launch. A rewrite before you have numbers solves problems you may never have and creates new ones you cannot see yet.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.