Shimira IT
AI builders like Lovable, Bolt, Replit, v0, and Cursor have changed who gets to build software. A founder with no engineering background can go from idea to a working, clickable product in a weekend. That's genuinely good news.
What these tools don't do by default is the unglamorous engineering that paying customers depend on. The prototype works on the happy path, when you're the only user, on your laptop, clicking in the right order. Real users press back mid-checkout, open the app on a five-year-old phone, and submit forms twice.
Closing that gap is ordinary software engineering. But which builder you used changes what's likely broken, because each one leaves a recognisable fingerprint. This page explains the four things that go wrong in every AI-built app, then points you to a detailed checklist for your specific tool.
The four failure categories
Almost everything we find in an AI-built app falls into one of these, in this order of urgency.
1. Data exposure
The most serious, and the most common. AI builders wire your app's front end directly to a database using a public key, which is fine, so long as access rules restrict each user to their own data. When those rules are missing or too permissive, anyone who opens your app can read everything in it.
This isn't theoretical. In March 2025, security researcher Matt Palmer disclosed CVE-2025-48757, an exposure affecting more than 170 production apps built with Lovable, all traced to missing database access rules. A Q1 2026 audit of roughly 5,600 AI-generated apps by Escape.tech found that the large majority contained at least one critical vulnerability.
2. Secrets in the browser
Some keys are meant to be public. Others, especially database admin keys and payment secret keys, give full access to everything and must never leave your server. AI builders sometimes place them where the browser can read them, and anything the browser can read is public.
3. Money and accounts
Payment integrations that grant access on a redirect rather than a verified webhook, so some people get access without paying and some who paid get nothing. Password resets that open the wrong page. Sessions that never expire. These only surface with real customers.
4. Structure that collapses under change
The "fix one thing, break five" loop. Past a certain size, the AI can no longer hold the whole codebase in view, so it solves the problem in front of it and quietly contradicts a decision it made earlier. Every prompt costs credits and moves sideways.
What differs by builder
The four categories above are universal. Where they show up depends on your tool.
Lovable builds a React front end on a Supabase backend, synced to GitHub. Problems concentrate in database access rules, storage bucket permissions, and edge functions that don't verify who's calling them. → Lovable production checklist
Bolt.new builds in the browser, hosted on Bolt Cloud or Netlify, often with Supabase. The distinctive problem is size: large projects outgrow the agent's context window, leaving the same thing built several different ways in different files.
Replit Agent writes the code, provisions the database, manages the secrets, and publishes the app from one chat. The convenience is the catch: everything your app depends on lives inside one platform, configured by an agent, with no clean path out.
v0, Cursor, and Claude Code produce Next.js and React code in your own repository. Ownership is not the issue here. Architecture drift across hundreds of AI edits is, along with no tests guarding the flows that make you money.
The signal that prompting has stopped working
AI builders are excellent at generating features and much weaker at diagnosing problems that span several systems at once: the database, the payment provider, and the front end together. That's not a flaw you can prompt your way around, because the tool can only see part of the picture.
A practical rule: if the same bug has survived three rounds of prompting, it's structural. More prompting won't fix it, and every attempt makes the codebase slightly less consistent.
Other signals it's time to bring in an engineer:
- Your builder's own security scan flags issues you don't know how to act on.
- You can't confidently say who can read the data in your database.
- Payments work in test mode and you don't trust them with live cards.
- The app only runs inside the builder, not on your own domain and hosting.
- You're spending more credits undoing changes than making progress.
What doesn't need to happen: a rewrite
The most common advice founders get at this point is to throw the prototype away and build it properly. That's almost always wrong, and it's expensive.
Your prototype is the most precise specification you will ever write. It encodes your screens, your flows, and your business rules, the part that's genuinely hard to communicate. The engineering work is to keep that and make it hold up: lock down the data, move secrets server-side, make payments reliable, and add tests on the flows that matter.
Most AI-built app rescues are a few weeks of work, not a rebuild from a blank page.
Where to go next
Start with the checklist for your builder, and work through it in order. The data and secrets items come first, always, because those are the failures that end companies rather than just annoy customers.
If you'd rather someone else did it, that's what our AI-built app rescue service is for: a written audit with a fixed price for the whole job, and everything delivered in your own GitHub, hosting, and database accounts. We also have dedicated pages for Lovable, Bolt, and Replit.
Send us the project link and we'll tell you honestly where it stands, including when it's in better shape than you feared.