Vibe coding with Cursor, Lovable, or Bolt—when it breaks in production

Cursor, Lovable, Bolt, and friends are excellent at one job: turning a product idea into something clickable fast. The trouble starts when that demo meets real users, real secrets, and a real deploy pipeline.

If your vibe-coded MVP “worked last week” and now fails in staging, you’re not alone. Here’s what usually breaks—and the order of fixes that saves budget.

What breaks first in production

• Env and secrets: keys in the client bundle, missing production env vars, or committed .env files
• Auth edge cases: happy-path login works; roles, session expiry, and password resets don’t
• Deploy drift: “works on my machine” with no reproducible CI/CD or rollback
• AI cost spikes: unbounded model calls with no timeouts, caching, or budgets

Fix order that usually costs less

1. Stop the bleeding: rotate leaked keys, lock admin routes
2. Make deploy boring: one path to staging you can repeat
3. Stabilize money/user paths before new features
4. Add smoke tests (and tiny evals if AI is in the loop)
5. Only then rewrite the modules that stay toxic

A panic rewrite feels productive. A triage that restores deploy confidence usually ships value sooner.

When to call for rescue

If you can’t cold-start the repo, can’t explain a critical path, or every small change breaks three others, you’re in rescue territory. Run the free scorecard first—then book a short call if the score says salvageable or high rewrite risk.

For a deeper decision framework, see rescue vs rewrite and our rewrite-or-rescue guide.