Vibe Coding
Vibe Code Rescue: How to Fix a Broken Lovable, Bolt, or Replit App
Vibe coding is a real superpower — until a prototype gets shipped to production with the database wide open. Here's the exact triage we run to harden a vibe-coded app, and the honest call on when to rescue versus rebuild.
Last updated July 1, 2026 · by Scott Weber, Constant Concepts AI
Key takeaways
- →Almost every broken vibe-coded app fails in one of three ways: database rules off, secrets in client code, or no server-side auth boundary.
- →The 10-point triage below is the exact order to fix them — row-level security first, key rotation second.
- →Rescue vs. rebuild comes down to three things: data-model integrity, auth architecture, and framework fit. Most apps can be rescued.
- →Vibe coding isn't the problem. Shipping a prototype as production is.
We run our own agency on AI-accelerated development — Claude Code writes a large share of what we ship. So this is not an anti-vibe-coding piece. It's the opposite: the tools are good enough that founders are shipping real products with them, and the ones that break in production almost always break the same handful of ways. Here is how to find those failures and fix them, in priority order.
Why do vibe-coded apps break in production?
Vibe-coded apps break because AI generators optimize for "it works on my screen," not "it's safe with real users and real data." The result is a working demo missing the invisible layer — access rules, secret handling, server-side auth — that separates a prototype from a product.
The data backs this up. Veracode's GenAI Code Security Report found that 45% of AI-generated code failed security tests against the OWASP Top 10 (across 100+ models and 80 tasks). Per a Beesoul audit reported by The Next Web, roughly 70% of Lovable and Bolt apps built on Supabase ship with row-level security disabled — the exact hole that lets one user read everyone's data. And Hostinger's analysis of 30M+ commits found AI coding tools produced only about 3.6% quarterly output gains, concentrated among senior developers — a useful reminder that the tools accelerate people who already know what safe looks like. Vibe-coding's technical-debt pattern is now formal enough to have a peer-reviewed paper.
The incident file: what's already gone wrong
These aren't hypotheticals. Real vibe-coded apps have leaked real user data at scale in 2025–2026 — the same three failure classes, over and over.
Lovable — CVE-2025-48757
Roughly 170 of 1,645 scanned Lovable apps were found exposing user data through missing access controls, per Semafor's reporting on the disclosed vulnerability. (Semafor)
Moltbook — 1.5M tokens exposed
A misconfigured database left roughly 1.5 million API tokens and 35,000 email addresses publicly accessible, per Wiz Research. (Wiz Research)
The 'delete the production database' class
AI agents with write access to production have wiped live data. The lesson isn't 'AI is reckless' — it's that no generator should ever hold unguarded production credentials.
The 10-point rescue triage
Work these in order — the first four stop active data exposure, the rest make the app operable and resilient. If you do nothing else today, do numbers 1 through 3.
Turn on Row-Level Security on every table
The single most common failure. If your database lets any logged-in user read any row, fix this first — before anything else touches production.
Rotate every key that ever touched client code
Assume any API key, token, or secret shipped in the browser bundle is already public. Rotate them all, then never put a secret in client code again.
Move secrets to the server
API keys, service credentials, and privileged tokens belong in server-side functions or a secret manager — never in the frontend, never in a public repo.
Add server-side auth checks on every mutation
Client-side 'if user is admin, show button' is not security. Every write and every privileged read needs a server-side check that the caller is actually allowed to do it.
Add rate limiting
Unthrottled endpoints get abused — scraped, brute-forced, or run up into a surprise bill. Rate-limit auth, form submits, and any expensive operation.
Turn on error monitoring
You cannot fix what you cannot see. Wire up error tracking so production failures reach you before they reach a customer or a headline.
Set up backups and a rollback path
Automated database backups and a tested restore. One bad migration or one deleted table should be a five-minute recovery, not a company-ending event.
Verify the payment flow end to end
Confirm amounts, currencies, webhooks, and refund paths against the payment provider's dashboard — with real test transactions, not a trust-the-generator assumption.
Take the deploy pipeline off 'click to publish'
Production deploys should run through a build with type checks and tests, not a one-tap publish that pushes whatever is in the editor straight to your customers.
Audit dependencies and CVEs
Scan for known-vulnerable packages and outdated dependencies. AI-generated apps pull in a lot of libraries fast; some of them have public exploits.
Want this as a printable checklist plus a free look at your app? We'll tell you in 48 hours whether to harden or rebuild — with a fixed quote either way.
Get a free rescue audit →Should you rescue it or rebuild it?
Rescue when the data model is sound, auth can be retrofitted cleanly, and the framework is one you'd have chosen anyway. Rebuild when the data model is fundamentally wrong, auth is tangled through the whole app, or the stack can't support where you're going. Most apps are rescues — a rewrite is the exception, not the default.
Rescue if…
- Your tables and relationships make sense
- Auth is missing, but can be added cleanly
- The framework fits your roadmap
- The core flows already work for users
Rebuild if…
- The data model would need re-architecting
- Auth logic is smeared through every file
- The stack can't scale to your plan
- You're fighting the generated code more than using it
Vendors report a wave of teams paying to rebuild AI-generated apps — one estimate cites around 8,000 startups and rescue quotes of $50K–$500K (Creatr, vendor-reported). Treat those as directional estimates, not gospel — most of the apps we see need a hardening pass, not a rewrite.
What a professional hardening pass looks like
A hardening pass keeps everything that works and replaces everything that's dangerous: security rules on the database, secrets moved server-side, real auth boundaries, monitoring, backups, and a proper deploy pipeline. You keep the product; you replace the missing operational layer.
Our own stack is Next.js and Firebase, so a typical rescue looks like: lock down Firestore/Supabase security rules table by table, move every credential into server-side functions and a secret manager, add server-verified auth on all mutations, wire error monitoring and automated backups, and put deploys behind a build with type checks and tests instead of one-tap publish. We keep the prototype's UI and flows — those are the parts vibe coding is genuinely great at — and rebuild only the invisible layer underneath. If you want the deeper background on where AI-assisted development shines and where it needs a human, our what Claude Code cannot do playbook is the companion to this one.
How to prevent this on your next build
Vibe-code the prototype — genuinely, it's the fastest way to validate an idea. Then, before real users and real data arrive, run the 10-point triage as a launch gate rather than a post-incident cleanup. The rule that keeps you safe: a demo proves the idea; a launch gate makes it a product. If you're still deciding whether to build with an agency or a no-code tool in the first place, start with what vibe coding actually is and the AI readiness assessment.
FAQ
Can I keep my Lovable, Bolt, or Replit app?
Usually yes. If the data model and core flows are sound, most vibe-coded apps can be hardened in place — secured, monitored, and put on a real deploy pipeline — without a rewrite. The rebuild call comes down to auth architecture and data integrity, which is exactly what the rescue-vs-rebuild section covers.
How much does a vibe-code rescue cost?
It depends entirely on what's broken. A focused hardening pass (security rules, secrets, auth, monitoring, deploy pipeline) is a fraction of a full rebuild. Vendors circulate rescue figures in the $50K–$500K range, but treat those as estimates — the honest answer requires an audit first, which is why we quote a fixed number after looking, not before.
How do I know if my data already leaked?
Check for row-level security being off, secrets in your client bundle or public repo, and any endpoint returning more than the current user should see. If any of those are true, assume exposure: rotate keys, review access logs, and treat it as an incident. When in doubt, get a second set of eyes on it fast.
Is vibe coding safe for business apps?
The tools are genuinely good — we use Claude Code every day. The danger is not the AI; it's shipping a prototype as production without the security, testing, and operational layer a real app needs. Vibe-code to move fast, then harden before real users and real data show up.
Broken app? Get a free rescue audit.
We'll review your vibe-coded app and tell you in 48 hours whether to harden or rebuild — with a fixed quote either way. No pressure, no rewrite-by-default.
Get a free rescue audit →Keep reading: what is vibe coding, Claude Code use cases, mobile app vs. PWA, and when your website isn't converting.
Ready to stop doing this manually?
We map your workflows, deploy the right AI Worker, and guarantee the math pencils out before you sign.