My vibe-coded app broke in production. Now what?

First: breathe. Then triage.

You shipped something customers actually use. It was built mostly with AI help — Cursor, Claude, ChatGPT, maybe a weekend of pure momentum — and for a while it worked. Then production disagreed. A payment failed. Logins looped. A deploy made everything worse. This is the worst week of a lot of founders' lives, and it is also more common than the internet admits.

This is not a lecture about "building the right way." It is a calm order of operations for the next 48 hours.

Hour 0–2: stop the bleeding

Before you open the editor, decide what "safe" looks like right now.

1. Take payments offline if charges, refunds, or subscriptions look wrong. A quiet storefront beats a noisy chargeback pile.
2. Freeze deploys. No more "one quick fix" pushes until you know what changed.
3. Rotate secrets if you suspect a leak, a public repo, or a .env that traveled somewhere it shouldn't.
4. Tell customers something true and short if they can already see the failure. Silence creates worse stories than a status note.

If you have a staging environment that still works, leave production alone until you can reproduce the bug there. If you don't have staging, that is useful information for later — not a reason to keep poking live.

Hour 2–6: gather evidence, not opinions

AI-written apps often fail in confusing ways because nobody built a map. Your job now is to collect artifacts a senior engineer can use without a séance.

• Exact error messages and screenshots
• Timestamps of when it started (and what you shipped near that time)
• Browser, device, and whether it is one user or many
• Server logs, payment provider logs, auth provider logs
• The last known-good commit, tag, or deploy

Write down what you already tried. Failed experiments are data. Re-running the same AI prompt with "please fix" is not a strategy.

What usually breaks in vibe-coded apps

Patterns we see over and over when AI did most of the scaffolding:

• Auth that almost works — sessions, cookies, and role checks that were pasted from three tutorials and never reconciled.
• Payments with happy-path only — no webhook verification, no idempotency, no handling for "paid in Stripe, missing in our DB."
• Environment drift — works on your laptop because of a local secret, a seeded database, or a feature flag nobody named.
• Silent data bugs — duplicate rows, soft-deleted records that aren't, and migrations that were "applied" by the model in chat but never in production.
• Dependency soup — packages pinned to whatever the model liked that day, with no lockfile discipline.

None of these mean the product idea is dead. They mean the foundation needs adult supervision.

Hour 6–24: decide rescue vs. rebuild

You do not need a perfect architecture decision tonight. You need a direction.

Lean rescue if customers already depend on the app, the core flows are understandable, and the worst bugs sit in a few dangerous surfaces (auth, money, data integrity). Stabilize those first. Everything else can wait.

Lean rebuild (of a slice, not necessarily the whole product) if nobody can explain how login or billing works, there are no tests and no way to add them safely, or every fix creates two new failures. Sometimes the kindest move is to freeze the old app as a read-only bridge and rebuild the critical path cleanly.

We wrote a longer decision guide in How to tell if your AI-built app is worth saving. Use it when you have slept.

What not to do this week

• Don't paste production secrets into a random chat to "debug faster."
• Don't rewrite the entire frontend because the bug felt frontend-y.
• Don't hire the cheapest overnight freelancer to "just get it green." Panic labor compounds debt.
• Don't disappear from customers while you argue with the model.

When to call for help

Call someone senior when money or personal data is at risk, when you cannot reproduce the failure, or when you have already spent two full days looping on the same symptom. A short triage call should leave you with a written priority list — not a sales pitch dressed as empathy.

If that is the boat you're in, AISlop.Surgery is how we run that triage: diagnose first, stabilize the dangerous parts, then decide what is worth keeping. No judgment. The AI got you far enough to have a real problem. That is a better starting point than a blank repo.