AI app builders have changed who can ship software. Founders are building working prototypes in Lovable, Bolt, Cursor, and Replit over a weekend — and that’s genuinely great. The problem shows up later: the app works perfectly for you, then real users, real data, and real attackers arrive, and things break in ways the demo never showed.
I’ve reviewed a growing number of these apps this year. The good news: most don’t need a rebuild. They need a specific set of fixes that AI tools consistently skip.
Why AI-Built Apps Break in Production
AI coding tools optimise for “it works when I click through it.” Production needs “it keeps working when 500 people use it in ways you didn’t expect, and someone is actively trying to break it.”
The gap is almost always the same set of invisible things: who is allowed to see what, what happens when something fails, and where the secrets live. None of that shows up in a demo with one user.
The 7 Things to Check Before Launch
| Issue | What it looks like | Why it matters |
|---|---|---|
| Exposed API keys | OpenAI, Stripe, or database keys in frontend code | Anyone can copy them and run up your bill or read your data |
| Open database rules | Supabase/Firebase tables readable or writable by anyone | Every user’s data is public to anyone who looks |
| Browser-only auth checks | ”Admin” pages hidden in the UI but not protected on the server | Users can access other people’s accounts or admin actions |
| Unverified payment webhooks | Stripe events accepted without signature checks | Someone can fake a “payment succeeded” event |
| No input validation | Forms send whatever the user types straight to the database | Broken data, injection attacks, crashes |
| No error handling | One failed API call shows a blank screen | Users leave and you never find out why |
| No backups or monitoring | Nobody knows when it’s down or if data is lost | One bad deploy can wipe customer data permanently |
If you’re not sure about any of these, that’s the answer — it needs checking. The website security guide covers the ongoing side once you’re live.
Fix or Rebuild?
Most founders assume they need to start over. Usually they don’t.
Fix it if: the data model makes sense, the main user flows work, and the problems are mostly security, validation, and error handling. That’s the common case.
Rebuild parts of it if: the same logic is copy-pasted across dozens of files, the database structure doesn’t match how the business works, or every change breaks two other things. AI tools are prone to this when a project has gone through hundreds of prompts without anyone owning the structure.
A proper review answers this question in days, before you spend money in the wrong direction.
What a Rescue Actually Costs
| Stage | Typical cost | Timeline |
|---|---|---|
| Pre-launch review (security + architecture) | $500–$1,500 | 2–4 days |
| Fixing issues found in review | $2,000–$8,000 | 1–3 weeks |
| Rescue of a live, unstable app | $5,000–$15,000 | 2–6 weeks |
| Partial rebuild (core data + backend) | $8,000–$25,000 | 4–8 weeks |
The pattern is consistent: catching problems before launch costs a fraction of fixing them after a data leak or a failed payment run. Compared to the full cost of a custom web app, an AI-built prototype plus a professional hardening pass is often the cheapest route to a real product.
The Setup That Works Going Forward
You don’t need to stop using AI tools. The setup I recommend to founders:
- A developer owns the foundations — authentication, database rules, payments, deployment, and backups.
- You keep building with AI for screens, copy, and small features.
- Automated tests and a review step catch AI changes that quietly undo security fixes.
- Monitoring and alerts so you hear about errors before customers do.
This keeps the speed that made vibe coding attractive, without betting the business on code nobody has checked. It’s the same balance covered in what AI coding tools can and can’t do.
Built something with AI and want to know if it’s safe to launch? Send me the link. I’ll review the app and tell you plainly what needs fixing, what can wait, and whether a fix or rebuild makes more sense.