Solution
Fix a vibe-coded app before it reaches real users
Last reviewed , published by Gjethe
To fix a vibe-coded app, first check what the AI may have missed: secret keys visible in the browser, database tables anyone can read, permission checks done only in the interface, and payments that trust the client. Close those gaps, then fix bugs with tests in place, clean up duplicated code, and deploy with monitoring and backups. Most apps can be repaired rather than rebuilt.
- 1Get the code out
- 2Rotate and hide secrets
- 3Lock down the data
- 4Test the critical flows
- 5Fix and de-duplicate
- 6Deploy properly
How do you fix a vibe-coded app, step by step?
- 1
Get the code out
Export or sync the project to a Git repository you own. Every later step depends on version history.
- 2
Rotate and hide secrets
Any key that ever appeared in front-end code or Git history should be replaced, then stored in environment variables.
- 3
Lock down the data
Enable Row Level Security or tighten Firebase rules, and move permission checks to the server.
- 4
Test the critical flows
Write automated tests for sign-up, login, payment and the core feature before changing them.
- 5
Fix and de-duplicate
Fix bugs at their cause, and merge the near-identical copies of logic AI tools tend to generate.
- 6
Deploy properly
Separate staging and production, add error tracking, uptime checks and tested backups.
Vibe coding, a term Andrej Karpathy popularised in February 2025, means building software by describing it to an AI and accepting the code it writes. It has put working products in the hands of people who could never have built them before. It has also produced a wave of apps that look finished but haven't been checked by anyone who reads code. This guide explains what to check, what to fix first and when to bring in a developer.
What are the stages of fixing a vibe-coded app?
AI prototype
Built with Lovable, Bolt, v0 or Cursor
Audit
Code, data rules, secrets and deployment
Secure
Keys rotated, access rules and auth fixed
Stabilise
Bugs fixed, logic cleaned up, tests added
Production
Monitored, backed up and documented
Can you check your own app? A ten-point self-check
You don't need to read code for most of these. If any answer is “no” or “I don't know”, the app needs a review before launch.
- Open the page source and search for “key” or “secret”: no private API keys should appear
- Every Supabase table has Row Level Security switched on, with policies that match who should see what
- Firebase security rules are not in test mode and don't allow open reads or writes
- A logged-out visitor can't open admin pages or call admin actions by guessing the URL
- One user can't see another user's data by changing an ID in the address bar
- Prices and plans come from the server or the payment provider, never from the browser
- Payment webhooks are verified with the provider's signing secret
- Secret keys live in environment variables, not in files committed to Git
- Someone is told when the app throws errors, through a tool like Sentry
- The database is backed up and you have tried restoring it
Why does AI-generated code need a review?
AI models write code that answers the prompt. They are much less reliable at the things nobody asked for: which user should be allowed to do this, what happens with unexpected input, what if two requests arrive at once. Veracode tested more than 100 models on 80 coding tasks in 2025 and found that 45% of the results introduced a known class of security flaw, with no clear improvement in larger or newer models.
The consequences are real. In 2025 a researcher scanned 1,645 apps from the public showcase of one AI app builder and found 170 whose database tables could be read using only the public key shipped to every browser, because Row Level Security had not been enabled. The issue was recorded as CVE-2025-48757. The platform disputed responsibility, noting that each app owner controls their own data rules, which is exactly the point: the owner has to check.
Which problems appear in which AI tools?
The tool matters less than the stack it generates. These are the patterns we look for first.
| Tool or stack | Typical set-up | Check first |
|---|---|---|
| Lovable | React, Vite and Supabase | Row Level Security on every table, keys in the client bundle |
| Bolt.new | React or Next.js, often with Supabase | Secrets in code, server routes without authentication |
| v0 | Next.js and React components | Server actions without permission checks, client-only rendering |
| Replit | Full-stack apps hosted on Replit | Secrets handling, database access, export and hosting plan |
| Cursor, Claude Code, Copilot | Any stack, inside your own repository | Duplicated logic, missing tests, unreviewed dependencies |
When should you stop prompting and call a developer?
A useful rule: if the same bug has survived three attempts, the cause is probably structural. Each new prompt tends to add a workaround rather than fix the root, and the codebase gets harder to change with every round. That's the moment for someone to read the code rather than describe it.
Bring in a developer before launch if the app stores personal data, takes payments or is used by a business to run its operations. In those cases the cost of a missed security gap is far higher than the cost of a review.
Common mistakes when fixing AI-built code
Asking the AI if the code is secure
A model reviewing its own output tends to agree with itself. Use a person or a dedicated scanner, ideally both.
Fixing symptoms in the interface
Hiding a button doesn't stop the request behind it. Permissions belong on the server and in the database.
Deleting keys without rotating them
A key removed from the code is still valid, and still in Git history. Replace it at the provider.
Adding packages the AI suggested blindly
Models sometimes suggest packages that don't exist or are outdated. Check each one before installing it.
Our view
Sources and further reading
Frequently asked questions
What is a vibe-coded app?
An app built mostly by an AI model from plain-language prompts, where the builder accepts the code without reviewing it in detail. Lovable, Bolt, v0, Replit and Cursor are common tools.
Are vibe-coded apps safe?
Not by default. Many are fine for demos but have gaps that matter with real users, especially open database tables, exposed keys and permission checks done only in the interface.
Can I fix my vibe-coded app myself?
You can run the self-check on this page and fix some issues by prompting carefully. For apps that handle personal data or payments, a developer review is worth it before launch.
Do I need to rebuild my app from scratch?
Rarely. Most AI-built apps have a working core. Rebuilding makes sense when the data model is unsafe at its core or the app is small enough that repairing it costs more.
How do I check if Supabase Row Level Security is enabled?
In the Supabase dashboard, open the table editor or the authentication policies page. Each table shows whether RLS is enabled and which policies apply. A table with RLS off is readable with the public key.
What does it cost to fix a vibe-coded app?
It depends on the size of the code, the data it handles, its integrations and whether it already has users. We quote an audit first, then quote the fixes from what it finds.
Services that make it happen
Vibe-Coded App Repair
Secure, debug and ship apps built with Lovable, Bolt, v0 or Cursor.
Secure Code Review
Review your codebase for security flaws before release.
MVP Development
The smallest product that proves your idea.
QA & Software Testing
Manual and automated testing across browsers and devices.
Cloud Deployment
Vercel, AWS, Azure and Google Cloud set up properly.
Web Applications & SaaS
Portals, dashboards and subscription products.
Keep reading
Talk it through with us.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project