What breaks first when an AI-generated MVP gets real traffic

Your app works. You built it fast, a handful of people are using it, and everything’s smooth. Then you get a spike, a launch, a shoutout, and suddenly pages hang, the database throws errors, and your bill jumps. The code didn’t change. What breaks first when traffic gets real is predictable, and you can fix most of it in an afternoon.

Why this happens

AI coding tools optimize for “works now,” not “works at 1,000 requests a second.” That’s the right call for an MVP. You want to see the thing run. But the defaults that make a demo work are the same defaults that fall over under load. The app isn’t broken, it just was never tuned for volume, and nobody told you which knob matters.

Failures show up in a reliable order. Here’s the order, and what to do about each.

How to fix it, in the order things break

1. Database connections run out first.

This is almost always the first wall you hit. Every request that talks to the database opens a connection. Postgres has a hard limit, usually around 100. Serverless functions make it worse, because each cold start can open its own connection and not release it. At low traffic you never notice. At a spike, you get remaining connection slots are reserved or too many clients already, and the whole app stops.

Check your current limit and how close you are:

-- Max allowed connections
show max_connections;

-- Connections in use right now, grouped by state
select state, count(*)
from pg_stat_activity
group by state
order by count(*) desc;

If active plus idle is anywhere near max_connections, you’re one spike from an outage. The fix is a connection pooler like PgBouncer sitting between your app and Postgres. It holds a small pool of real database connections and shares them across thousands of incoming requests. Your app thinks it has unlimited connections, Postgres only ever sees a handful.

2. Slow queries turn into stuck queries.

A query that scans the whole table is fine when the table has 200 rows. At 200,000 rows it takes seconds, and under load those slow queries pile up and hold connections open, which feeds right back into problem one. The usual culprit is a missing index on a column you filter or join on.

Find your worst queries:

-- Requires the pg_stat_statements extension
select
  round(mean_exec_time::numeric, 1) as avg_ms,
  calls,
  substring(query, 1, 80) as query
from pg_stat_statements
order by mean_exec_time desc
limit 10;

For any slow one, run explain analyze on it. If you see Seq Scan on a big table, add an index on the column in your where or join:

create index concurrently idx_orders_user_id on orders (user_id);

Use concurrently so the index builds without locking the table against live traffic.

3. No caching means every request does full work.

AI-generated apps rarely cache anything. Every page load recomputes the same data from scratch. The homepage that queries “top 10 products” runs that query for all 1,000 visitors in the same second, even though the answer is identical. Cache results that don’t change per user, even for 30 seconds, and you cut database load by a huge margin. An in-memory cache or Redis in front of expensive reads is the standard move.

4. Everything happens inside the request.

Sending an email, resizing an image, calling an AI model: MVPs do these inline, while the user waits. Under load, a slow third-party call ties up your server and connections for seconds per request. Move anything that doesn’t need an instant answer into a background job queue. The request returns fast, the work happens after.

5. No limits means one user can take down everyone.

Without rate limiting, a single script (or a bot) can hammer an endpoint thousands of times a second and starve every other user. A basic per-IP rate limit is a small change that prevents one bad actor from becoming an outage for all.

The pattern across all five: an MVP does the simplest thing per request, and “simplest” stops scaling once requests multiply. You don’t need to rewrite the app. You need a pooler, a few indexes, some caching, a job queue, and a rate limit.

A quick way to find your own ceiling. You don’t have to wait for a real spike to see which of these bites first. Point a small load test at your busiest endpoint and watch what fails. A one-liner with hey sends a burst and reports the errors:

# 500 requests, 50 running at once, against your real endpoint
hey -n 500 -c 50 https://your-app.com/api/items

If you get 500s and the database logs mention connections, it’s problem one. If every response is 200 but the slow ones take seconds, it’s a missing index. The failure the test surfaces first is the one to fix first, and then you run it again. This turns “I hope it holds” into a number you can actually improve before launch day.

The order matters because these problems feed each other. Slow queries hold connections open longer, which drains the pool faster, which turns a latency problem into a hard outage. Fix them from the bottom up: pooler first so you stop falling over, then indexes so queries stop hogging connections, then caching and queues so you’re doing less work per request in the first place.

Or, we do it for you

A production audit runs exactly this checklist against your live app: connection headroom, slow queries, missing indexes, and the caching and queue gaps that surface under load, with the specific fixes ranked by impact. If you want a second pair of eyes on your setup regardless of what you built it with, get a free production audit.

FAQ

How much traffic can an untuned AI-generated app actually handle?

It varies, but the connection ceiling usually bites somewhere between 50 and a few hundred concurrent users, well before you’d expect. The exact number depends on how many queries each request runs and how long they take. The point is that the wall is closer than most founders assume, and it arrives suddenly, not gradually.

Do I need to rewrite my app to scale it?

Almost never. The first fixes (a connection pooler, a few indexes, basic caching) are additions, not rewrites. You’re tuning the app you have, not rebuilding it. Rewrites become worth considering much later, at a scale most apps never reach.

What’s the single highest-impact change?

A connection pooler, in most cases. Running out of database connections is the most common first failure and the one that takes the whole app down at once. PgBouncer in front of Postgres often buys you an order of magnitude more headroom for an afternoon of setup.

How do I know which query is slow without guessing?

Turn on the pg_stat_statements extension and sort by mean execution time, as shown above. It tells you exactly which queries are slow and how often they run, so you fix the ones that actually hurt instead of guessing from the code.