The short answer
Most vibe-coded apps should be fixed, not rebuilt.
Fix it if the main user flows work and the problems are security settings, missing tests or messy code. Rebuild only when the data model is wrong for the business, auth was bolted on late, or every fix breaks something else. Either way, lock down your data first.
Lovable, Bolt, Replit and Cursor let a founder or an operations manager build a working product in a weekend. I use AI coding tools every day, and I think that is a good thing. But I have rescued more than 20 of these apps in the last 18 months, and the story is usually the same. The app gets traction, real customer data goes in, and nobody checks the parts the AI tool skipped.
The research matches what I see. Veracode tested code from more than 100 language models and found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability. Escape.tech scanned 5,600 public vibe-coded apps and found more than 2,000 high-impact vulnerabilities and over 400 exposed secrets, including medical records and bank details.
The five checks to run this week
You do not need to be a developer to run most of these. They are in order of urgency. If one fails, stop adding features until it is fixed.
- 1
Can strangers read your database?
Many AI-built apps use Supabase or Firebase, where the browser talks straight to the database. That is only safe if the database rules stop each user reading other people's rows. In Supabase, row level security (RLS) must be on for every table, with a policy on each one. Tables created with raw SQL do not get RLS automatically, and AI tools often create tables that way.
How to check: open each table in the Supabase dashboard and confirm RLS is on and has policies. In Firebase, make sure the rules do not allow all reads and writes.
- 2
Are secret keys sitting in the front end?
A Supabase anon key in the browser is normal. A service role key, a Stripe secret key or an OpenAI key is not. Anyone can copy it, read your whole database or run up your bill.
How to check: open the live app, open developer tools and search the loaded JavaScript for
sk_,service_roleandsecret. If you find one, rotate the key today and move that call to a server function. - 3
Does the server check who the user is?
AI tools often hide an admin button in the interface and call that access control. If the server never checks, anyone who knows the request can do what the button does.
How to check: log in as a normal user, copy the request that loads your own record, and change the ID. If another customer's data comes back, your permissions only exist in the browser.
- 4
Could you restore yesterday’s data?
Free tiers often have limited backups or none at all. A backup you have never restored is a hope, not a backup.
How to check: find out what backups exist, then restore one into a separate project and look at the data.
- 5
Does anything tell you when it breaks?
If customers are the first to tell you the app is down, add error tracking and uptime alerts. Both take an afternoon to set up and cost little or nothing at small scale.
Fix or rebuild: how to decide
Once the urgent security issues are closed, the bigger question is what to do with the code. These are the five signals I look at.
| Signal | Points to fix | Points to rebuild |
|---|---|---|
| Data model | Tables match how the business works | Key concepts missing or duplicated everywhere |
| Auth and permissions | One auth system, roles in one place | Checks scattered through the UI, several half-built logins |
| Change safety | Most changes stay where you made them | Every fix breaks two other features |
| Stack | Mainstream: React, Next.js, Postgres | Locked into a platform you need to leave |
| Next 12 months | Same product, more users | New product, or enterprise buyers with strict security reviews |
Mostly in the middle column? Fix it. That means locking down data access, adding tests around the flows that make money, breaking up the largest files and setting up a proper deployment pipeline. For a founder-stage app this is weeks of work, not months.
Several answers on the right? A rebuild is often cheaper over a year. The good news is that a working prototype is the best specification you will ever have. Every screen and rule has already been tested with real users, so the rebuild moves fast.
What it costs to fix a vibe-coded app
Prices in this market range from a few hundred dollars for an automated scan to tens of thousands for a full rescue. Be careful at both ends. A scan finds configuration mistakes but cannot tell you whether your data model will carry the business. A big rebuild quote may answer a question nobody asked.
Pay for a short, fixed-fee review first. It should give you a ranked list of findings, a clear keep, fix or rebuild call and a fixed quote for the work. Then you decide with real numbers.
Step 1 · 5 business days
Production Readiness Review
A$3,500 + GST, fixed
Findings report, keep, fix or rebuild call, and a fixed quote for the work.
Step 2 · 2 to 6 weeks
Harden and Ship Sprint
A$12k to A$35k + GST
Your CTO leads a small team of AI-driven developers to close the holes and ship.
The Australian angle: privacy and breach reporting
If your business is covered by the Privacy Act 1988, the Australian Privacy Principles apply to personal information in your app however it was built. That includes taking reasonable steps to protect it. If an exposed database leads to a breach likely to cause serious harm, you may have to notify the people affected and the OAIC under the Notifiable Data Breaches scheme. “The AI wrote it” is not a defence. Get advice on whether the Act covers you, and treat the five checks above as the minimum.
For IT leaders: the apps you do not know about
The same tools are now in every business team. In most organisations I talk to, someone in sales, operations or finance has built an internal app that touches customer or financial data, and IT has never seen it. Banning AI tools rarely works. Build an inventory, rate each app by the data it touches, and bring the useful ones under normal IT governance. Retire the rest before they cause an incident.
Our shadow AI apps guide sets out how to run that inventory, and our vibe code rescue service hardens the apps worth keeping.
Common questions
Is a vibe-coded app safe to launch?
It can be, but most are not safe by default. The common problems are database tables anyone can read, API keys in the front-end code, and auth checks that only run in the browser. Run the five checks in this guide before real customer data goes into the app.
How do I know if my Supabase database is exposed?
Open the Supabase dashboard and check that row level security is on for every table in the public schema, with policies that limit each user to their own rows. Then confirm the service role key appears nowhere in your front-end code. If either check fails, assume the data has been readable and fix it first.
When should I rebuild a vibe-coded app instead of fixing it?
Rebuild when the data model does not match how the business works, when auth and permissions were added late and are scattered through the code, or when each fix creates new bugs. In most other cases fixing is cheaper and faster.
How much does it cost to fix a vibe-coded app?
Our Production Readiness Review is a fixed A$3,500 plus GST and takes five business days. If the app needs work after that, a Harden and Ship sprint is usually A$12,000 to A$35,000 plus GST, quoted as a fixed price before any code changes.
