--- slug: app-breaks-in-production title: "When Your Vibe-Coded App Breaks in Production" excerpt: "A vibe-coded app breaks in production at the worst time. Here's a calm playbook for the first hour: what to check, what to roll back, and how to fix it." primaryKeyword: "vibe-coded app breaks production" publishedAt: 2026-08-29 readingTimeMin: 8 author: "Robert Boylan" tags: - debugging - production - incident-response - indie-dev - maintenance --- It's 11:47 PM. You're brushing your teeth. Your phone buzzes. A user just emailed: "the app is broken." You log in. The dashboard is white. Console errors you don't recognise. Three uptime alerts have piled up. You don't know what changed because the last thing you did was a quick prompt to Cursor at 3 PM that "seemed fine." This is the moment most indie devs find out they have no incident playbook. They had a clear plan for the build, a vague plan for the launch, and zero plan for the part where the thing they shipped catches fire. This post is the playbook. Specifically, what to do in the first hour when a vibe-coded app breaks in production, in the order you actually do it. Calm beats clever. A method beats panic. ## First, breathe. Then, slow down The instinct when production breaks is to immediately open Cursor and start prompting fixes. Don't. The first prompt fired in panic is almost always wrong, and a wrong fix on a broken app makes it harder to find the actual problem. The first ten minutes of an incident are about understanding what's broken, not fixing it. If you can stand up, get water, and do a single slow breath before opening anything, do that. Your future self in 45 minutes will thank you. The questions you're trying to answer in those first ten minutes: - **What's broken?** All of it, or some of it? Just signup? Just one feature? Just for one user? - **Since when?** Did this happen at the last deploy, or did it just start? If it just started without any deploy, the cause is probably external. - **How many users does this affect?** One angry tweet is different from your error tracker logging 4,000 events per minute. You don't know the answers yet. You're framing the search. ## Check the obvious places first The first hour of an incident is usually a process of elimination, not detective work. Check the most common causes in the most common places. **Your last deploy.** Open the hosting dashboard (Vercel, Netlify, Cloudflare, wherever your app lives). Look at the deploy log. Was the most recent deploy in the last few hours? Did it succeed? Did the build produce warnings nobody read? If the breakage started shortly after a deploy, the deploy is the first suspect. **Your error tracker.** If you have Sentry, Logflare, Highlight, or any error tracker wired up (and you should; install one before you launch, not after the first incident), the dashboard probably already has the answer. Top errors, sorted by frequency, time-bounded to the last hour. Read the top three. The pattern usually emerges in 30 seconds. **Your database.** Did you run a migration recently? Did something delete a column the app still queries? Did the database itself go down (it happens; Supabase, Postgres on Render, RDS all have occasional incidents)? Open the database dashboard and check status. **Your third-party services.** Is Stripe up? Is the auth provider up? Is the AI provider you wrap up? Check the status pages of every service you depend on. A "the app is broken" is sometimes "OpenAI is broken." Check before you blame your own code. In maybe 80% of incidents on a vibe-coded app, one of these four places has the answer in the first ten minutes. Resist the urge to start reading code before you've checked all four. ## When to roll back, when to patch forward You've identified the problem. Now the choice: roll back the last deploy and figure it out tomorrow, or fix the bug live. The rule, when you're under stress and short on time: **roll back**. Every modern host has a one-click revert to the previous deployment. Use it. The previous version was working five hours ago. Get back to it. The cost of a rollback is small: any new feature in the broken deploy is unavailable until you redeploy. The cost of "I'll just fix it" at midnight is large: you're now writing code while tired and panicked, on a broken app, in front of users. When to actually patch forward instead: - **The bug is in something the rollback would also break** (a database migration that's already partially run, an integration that's now in a new state) - **The fix is genuinely a one-line change you can verify in 60 seconds** (a missing env var, a typo in a string) - **The previous deploy is also broken** (the bug was there longer than the last deploy, and rolling back doesn't help) In every other case, roll back, sleep, fix in the morning. Production is not your IDE; it's a place where users live, and they'd rather see yesterday's working app than tonight's broken one with a half-applied patch. ## The fix loop with an AI tool Tomorrow morning, coffee, calm. Now the fix. Open your error tracker. Take a screenshot of the top error, including the stack trace (the list of files and line numbers where the error happened). Paste the screenshot into Cursor, Claude Code, or whichever tool you use, with one sentence of context: "this error started at the deploy at 3 PM yesterday; the last code change was [whatever you remember prompting]." This is the prompt that gets you to the fix fastest. The AI now has the symptom (the stack trace), the timing (when it started), and the recent context (what you changed). With that, "find the bug and fix it" is a precise question instead of a vague one. Two things to avoid in the fix loop: - **Don't accept a "comprehensive refactor" as the fix.** The AI will sometimes propose rewriting half a file. Decline. Ask for the smallest change that resolves the immediate error. Refactors during incidents make new incidents. - **Don't deploy directly to production.** If you have a preview deploy or a staging environment (you should; both Vercel and Netlify ship one per branch by default), push to a branch, verify the fix in the preview, then merge to production. Verify the fix is actually fixed by reproducing the original error path in the preview. If you don't know how to reproduce it, you probably don't know the fix works. ## What to do once it's calm The fire is out. The deploy is green. Users are emailing thank-yous instead of bug reports. Now do the small unglamorous things that prevent the next one. **Add the cause to a list.** Keep a running text file (a Notion page, a CLAUDE.md note, even a comment at the top of the relevant file) titled "Things that broke and why." For each incident: one paragraph, what broke, what caused it, what fixed it, what's now different. Three months from now when something similar happens, you'll thank yourself. **Add a guardrail.** If the breakage was preventable with a test, a type check, or a stricter linter rule, add it. One test per incident is the cheapest possible improvement. The AI is good at writing this test for you; just point at the file that broke. **Tell the affected users.** A short personal email to anyone who was affected, especially anyone who emailed you. "We hit a bug last night, fixed it this morning, sorry for the noise, let me know if you see anything else." Three sentences. The response from users who get a personal message about a bug they reported is universally positive, and "solo founder who actually replied" is itself a competitive advantage in indie SaaS. **Don't write a post-mortem nobody reads.** You're a solo founder. The CLAUDE.md note is the post-mortem. Don't spend an afternoon writing a Notion doc that no future hire will ever read. ## Wire the monitoring during the build, not after Almost every "the app silently broke in production" story ends with the founder installing Sentry that same week. The pattern is reliable enough that you should just install it during the initial build. What "minimal monitoring" looks like for an indie app: - An **error tracker** wired into the frontend and backend (Sentry's free tier works for years; Highlight and Logflare are also fine) - **Uptime monitoring** on the production URL (UptimeRobot or BetterStack, both have generous free tiers; pings the URL every five minutes, emails or texts you if it stops responding) - An **error notification path** that actually reaches you (a Slack channel, a Telegram bot, or your real phone number, not an email that gets buried in marketing) Add all three to the project spec when you describe the app, not as an afterthought after the first incident. Cursor, Lovable, or Bolt will wire them up as part of the initial scaffold; doing it later means going back and instrumenting code you've half-forgotten. [Maintaining a vibe-coded app six months later](/blog/maintain-vibe-coded-app) covers the bigger return-to-the-codebase problem this dovetails into. The other thing to capture in the spec: the rollback procedure. "If a deploy breaks production, use Vercel's instant rollback to the prior deployment." One sentence. You'll be glad it's written down at 11:47 PM when you're brushing your teeth. Production breaking is not a bug in your discipline. It's an inevitability of shipping. The difference between founders who handle it well and founders who handle it badly is not raw skill; it's having a method ready before you need it. Slow down, check the obvious places, roll back, fix tomorrow, write down the cause, ship the guardrail. That's the whole playbook. Print it; tape it to the wall; you'll need it within the first three months of any real launch.