The build got you 80% of the way. Then it broke and you couldn't fix it. Here's how to decide what to repair, what to ignore, and when to walk away.
A vibe-coded app is one you built fast with a tool like Cursor, Bolt, or Lovable — describing what you wanted and letting AI generate it. It works right up until it doesn't, and then you're staring at an error you didn't write and can't read.
This is the most common wall in vibe coding. It's not a sign you failed. It's a sign you've reached the edge of what "build it fast" gets you. What matters now is the decision, not the panic.
The pattern is predictable. The app works in the demo. You get users. Then a change breaks something, the AI's fix breaks something else, and each attempt digs the hole deeper. You've spent a weekend re-breaking the same feature.
The instinct is to keep prompting until it's fixed. Sometimes that works. Often it burns days on a problem that a five-minute decision should have settled: is this worth fixing at all, right now?
Before you write another prompt, name what kind of break this is. Three questions settle it.
Those three answers feed directly into the triage list below.
Sort every broken thing into one of these tiers before you fix anything. Work top-down. Never let a Tier 3 item eat a day while a Tier 1 sits open.
| Tier | What it looks like | Action |
|---|---|---|
| Tier 1 — Critical / blocking | Signup broken, payment fails, app won't load, data loss, security or billing bug | Stop everything. Fix now or take the feature offline until you can. |
| Tier 2 — Core-value degraded | Main feature works but is unreliable; a common flow errors intermittently | Fix this week. It's capping conversion and trust even if no one complains. |
| Tier 3 — Cosmetic / edge | Misaligned button, rare edge case, a nice-to-have that errors, ugly-but-working UI | Write it down. Do not fix now. Batch it for later or never. |
The trap is Tier 3 disguised as Tier 1 by your own anxiety. A wonky layout feels urgent at 11pm. It isn't. If it doesn't block a user or your revenue and it isn't getting worse, it's Tier 3 — no matter how much it bothers you.
"Here are the three things broken in my app: [list]. Help me sort them into critical, core-value, and cosmetic — and tell me the one to fix first."
For any Tier 1 or Tier 2 break, run this before you spend a single hour on it. It replaces gut feeling with a number.
Fill in five lines:
A worked example. A checkout bug takes an estimated 6 hours to fix. Your time is worth $80/hr, so the cost to fix is $480. The bug is quietly costing you two lost signups a month at $40/mo each — $80/mo in upside. Payback: $480 ÷ $80 = 6 months. That's still worth it, because it's a Tier 1 revenue blocker that compounds.
Now flip it. A cosmetic dashboard glitch takes an estimated 5 hours ($400 of your time) and unblocks $0 of revenue. Payback: never. That's a Tier 3 item you should not be touching this month, no matter how much it nags.
| Break | Cost to fix | Monthly upside | Verdict |
|---|---|---|---|
| Checkout bug (Tier 1) | 6 hrs × $80 = $480 | $80/mo & rising | Fix now |
| Flaky core feature (Tier 2) | 4 hrs × $80 = $320 | ~$150/mo (trust/churn) | Fix this week |
| Cosmetic glitch (Tier 3) | 5 hrs × $80 = $400 | $0 | Defer / skip |
Use your own hourly number and your own upside estimates. The point isn't precision — it's forcing "is this worth it?" into daylight before the panic answers for you.
Sometimes the honest answer is that the codebase is fighting you and every fix costs more than the last. Rebuild is on the table when three things are true: you can't make a small change without breaking two others, you don't understand enough of the code to reason about it, and the app has proven that people want it.
That last one matters most. Don't rebuild an app no one is paying for — that's not a technical decision, it's a business one. If you have paying users and a codebase you can't maintain, a clean rebuild with better structure (or a developer) can be the cheaper path over three months, even though it feels like going backward.
If you're not sure the app has earned a rebuild, the real question is demand, not code. Our guide on after vibe coding, what next helps you tell the difference.
Here's the uncomfortable part. For a lot of founders who land on this page, the app isn't the thing that's actually broken. The business layer is. The product runs fine — there's just no pricing, no positioning, and no way to get customers.
A working app with two paying users doesn't have a bug. It has a monetisation gap. Fixing the code won't fix that, and you can lose months polishing an app that a pricing change would have moved further in a week.
If your app runs but the revenue doesn't, the fix is elsewhere: see how to make money from your vibe-coded app and, once it's earning, how to get customers for a vibe-coded app.
Marcus diagnoses the real bottleneck — technical or commercial — and gives you one specific thing to do next.
Talk to Marcus free → 14-day free trial · Builder from $79/mo · cancel anytime