Why your AI-generated app breaks in production (and how to avoid it)

Your app works. You clicked through it in the preview, the buttons did the right things, the data showed up, and you shipped. Then a real person used it, and something you never saw went wrong.

This is the most common surprise in AI-assisted building, and it's not a sign you did something stupid. The preview is a controlled room with one well-behaved user: you. Production is a crowd of strangers doing things in an order you never imagined. The gap between those two is where AI-generated apps tend to break, and almost all of it is predictable. Here's what fails, why, and how to get ahead of it.

Your data assumptions were built for one user

In the preview you're the only person touching the app. So the generated code quietly assumes a world where nothing happens at the same time. One signup, one record, one tab. Then two users hit the same action at once and the assumptions fall apart.

The classic failures: two people grab the same "unique" username because nothing enforced uniqueness at the database level. A counter or balance updates wrong because two requests read the old value before either wrote the new one. State that lived comfortably in one browser session suddenly needs to be shared, and isn't. AI-generated code is especially prone to this because it optimizes for the demo that works, not the race condition that happens twice a week. The fix is to assume every action can happen twice, simultaneously, and to push real constraints, like uniqueness and atomic updates, down into the database where they actually hold.

The edge cases never came up because you behaved

You tested your app the way you built it, which means you used it correctly. You filled in the form. You uploaded a normal-sized image. You typed an email that looked like an email. Real users do none of this reliably.

Someone submits the form empty. Someone pastes a 40-megabyte photo. Someone enters an emoji where you expected a name, or a name where you expected a number, then hits back and resubmits. AI-generated apps frequently handle the happy path beautifully and have nothing behind it, so the first unexpected input throws an error the user sees raw, or worse, silently corrupts something. You don't need to predict every input. You need to decide what happens when input is wrong: reject it clearly, show a human message, and never let a bad value through to your data. This is one of the cliffs we cover in where people actually quit when building with AI, because it's exactly the kind of invisible work that's easy to skip.

Production isn't your laptop

The single most frustrating production bug is the one where nothing is wrong with your code. It worked locally and broke live because the environment changed underneath it.

The usual suspects are configuration. An API key that lived in your local environment was never set on the server, so the live app calls an integration with no credentials and fails. A database URL points at your laptop's test database instead of the real one. A setting that was fine in development mode, verbose errors, relaxed security, a permissive CORS rule, behaves completely differently once the build is in production mode. None of this shows up in the preview because the preview runs in development. The habit that saves you: keep a checklist of every secret, key, and setting your app needs, and verify each one exists and points at the right place in the live environment before you trust it.

Some bugs need a second person to appear

A whole class of problems is invisible until more than one user exists, which is exactly never during development. You are user one, and user one can't step on user two's data.

This is where ownership bugs hide. The app fetches "the user's documents," but the query forgot to filter by who's asking, so everyone sees everyone's data the moment a second account exists. A link to your dashboard works for you and also works for a stranger who changes the ID in the URL, because nothing checked that the resource belongs to them. These don't feel like security holes during building; they feel like working features, because with one user the right data is the only data. The way to catch them is to create a second test account and try to reach the first account's data on purpose. If you can, so can anyone.

Load is its own category of failure

Speed in a demo tells you nothing about speed under traffic. A page that loads instantly for one user can crawl when fifty arrive, usually because something runs once per request that should run once total, or because a query that scanned ten rows in testing now scans ten thousand.

You don't need to build for millions before launch. You do need to know that "fast for me" and "fast under load" are different claims, and not assume the first proves the second. The cheap insurance is to load your app with a realistic amount of test data, not three records, and click around. Most performance cliffs are visible the moment the data stops being tiny.

The mindset that prevents most of this

The throughline is simple: stop testing as the person who built the app, and start testing as a stranger who doesn't care about it. Builders use software gently. Real users, and attackers, do not.

So test like someone who wants to break it. Submit garbage. Open a second account and poke at the first. Change IDs in URLs. Refresh mid-action. Then check your configuration before every launch, because the boring stuff, a missing key, a wrong database URL, causes more outages than any clever bug. And before you go live, run a pre-launch scan to catch the ownership and exposure problems that don't announce themselves. This is also why tools matter: Kalit Flow (/flow) focuses on landing pages precisely because a page that's mostly design and a form has a far smaller surface to break than a full application, which is a reasonable thing to want for your first public thing.

None of this means AI-generated apps are unreliable. It means a working preview is the first draft, not the last. Here's the short version:

1. Assume every action can happen twice at once, and enforce uniqueness and atomic updates in the database.
2. Handle bad input on purpose: reject it, show a clear message, and never store it.
3. Check configuration before trusting production, every secret, key, and setting, because the environment differs from your laptop.
4. Create a second account and try to reach the first one's data, ownership bugs only appear with more than one user.
5. Test with realistic data volume so load problems show up before your users find them.

The preview proves your app can work. Production is where you prove it does. Close that gap deliberately and most of the scary surprises stop being surprises.