It works on your laptop and dies in production. What's actually wrong with the app you vibe coded

You built an app with Cursor, Lovable, Bolt, v0 or Claude. It runs on your machine. You showed it to someone and they were impressed. Then you tried to put it on the internet, something broke, and the AI that wrote the whole thing can’t tell you why.

Here’s the pattern I see over and over: the code the AI wrote is mostly fine. What breaks is the seams. Environment, network, auth, data, deploy, load. On your laptop none of these exist. One machine, one user, one database, every secret in a file the app can read. Production pulls those apart, and everything that was quietly held together by “it’s all on one machine” falls over at once.

Below are the seven ways it usually shows up, what’s actually going on underneath, and what fixing it tends to take. The hour ranges are the ones I publish on the rescue page. They’re ranges, not quotes.

1. Works locally, not in production

What you see. localhost:3000 is fine. The deployed URL shows a blank page, a 500, or a spinner that never stops.

What’s wrong. Almost always the environment. A .env file that never reached the host. A database URL that still points at localhost. An API the app calls that’s reachable from your network and not from the host’s. The code didn’t change. The world around it did.

I ran into the enterprise-sized version of this on an agent project. A chat component in the UI couldn’t reach the service behind it, because that service sat on a network the public internet wasn’t allowed to touch. Nothing in the code was wrong. The fix was a gateway between the two networks, configured to let exactly those calls through and nothing else. Your version is smaller, an environment variable or a connection string, but it’s the same seam.

What it takes. Usually inside the deploy range, 4–8 hours, because sorting this out is most of what “deploying” means.

2. The build is red and you don’t know why

What you see. It runs with npm run dev. On the host it fails with a wall of TypeScript errors or a missing module.

What’s wrong. Dev mode is forgiving and a production build isn’t. Type errors dev ignored are now fatal. A package installed locally but never added to package.json. A Node version the host picked that differs from yours. A filename whose case macOS forgave and Linux doesn’t.

What it takes. 2–6 hours. The log is long but decisive. The first real error is usually the whole story.

3. Login half works. Sometimes.

What you see. Signup works, but a refresh logs you out. Works in Chrome, not in Safari. Works for you, not for the friend you sent the link to.

What’s wrong. Auth is where AI tools produce the most confident-looking code with the most holes. Sessions stored client-side that vanish. Cookies set without the flags production HTTPS requires. Redirect URLs registered for localhost only. A protected page that checks auth in the browser and nowhere else, so the API behind it answers anyone.

What it takes. 6–12 hours. Not because any single fix is hard, but because every path has to be checked, and the half that works hides the half that doesn’t.

4. The API key is sitting in the client-side code

What you see. Nothing. That’s the problem. The app works. Somewhere in the JavaScript your browser downloaded is your OpenAI key, your Supabase service key or a Stripe secret.

What’s wrong. The AI needed the key to make the call and put it where the call was: in the front end. Anyone who opens dev tools has it. With an LLM key that’s a bill. With a database service key that’s your whole database.

What it takes. Move the call behind a server route, rotate the key, and check the git history, because the old key is still in there. A couple of hours per key, more if the app has no server side yet.

5. Migrations broke and the database isn’t what it should be

What you see. A column the code expects doesn’t exist. Or it exists locally and not in production. Or the migration runs and deletes something.

What’s wrong. The AI edited the schema in three places, the ORM model, a migration file and the hosted database’s dashboard, and they drifted. Local SQLite let things slide that Postgres doesn’t. There’s no single source of truth for what the database looks like, so every environment has its own.

Data wiring looks like plumbing and decides whether anything works. On the same agent project, connecting the upstream sources the agent read from and the downstream systems it wrote to was more of the work than the agent itself. Same at your scale. The model isn’t the risk. The data path is.

What it takes. 4–10 hours. Reconcile the schema, pick one source of truth, write a migration that moves production forward without losing rows, and run it against a copy first.

6. You’re not sure what “deploy” involves

What you see. The AI says “deploy to Vercel”. You have a Vercel account. You also have a domain somewhere, a database somewhere else, and no idea which parts connect to which.

What’s wrong. Nothing yet, and that’s the point. Deploy isn’t one button. It’s hosting, domain and DNS, environment variables, a production database, and a way to do all of it again next week without breaking anything. The first deploy by hand is fine. The third one by hand is where things get lost.

I deployed the backend of that agent project by hand exactly once. Then I automated it, because by the third change nobody could say which config was live. The pipeline isn’t overhead. It’s the only way “it works” stays true.

What it takes. 4–8 hours for hosting, domain, env and database, set up so the next deploy is a git push.

7. Works until two people use it at the same time

What you see. Fine while you test it. The moment a second person is on it, things slow down, or user A sees user B’s data.

What’s wrong. State kept in memory on the server, which was fine while there was one request at a time. A global variable holding “the current user”. A database connection opened per request and never closed. A rate limit on a third-party API you’re now hitting twice as fast.

What it takes. This one varies more than the others. A shared-state bug is an afternoon. A design that assumed one user everywhere means rebuilding the data layer, and I’d tell you that in the triage instead of starting to bill hours.

What all seven have in common

None of these is the AI writing bad logic. They’re the app meeting a world it was never run in. The fix is boring systems work: environment, network, identity, data, deployment. It’s the same work whether the app is a weekend project or a corporate agent. Only the size changes.

If one of these is your app right now, send me the repo or the URL. You get a written triage within two business days: what’s broken, what it takes, and an hour range I won’t exceed without asking you first. It’s free whether or not you hire me. Vibe coding rescue.

If it isn’t your own app but your team’s AI-written codebase (not stuck, just unread), that’s a different job: AI code audit.