The tools work. You describe an app and it appears. Then you try to put it live, take a payment or let a second person log in, and it stops.
I get this call regularly, and I want to be clear first: building something instead of talking about it for a year was the right instinct. The problem is not what you did, it is what these tools quietly leave out.
Why it stalls around 80 percent
AI builders are strong at the visible part. Screens, layouts, components, the flow between them. That is most of what you can see and a minority of what an app is.
They are weaker underneath. Who is allowed to read what. What happens when two people act at once. Where the data lives and whether it is protected. What happens when a payment fails halfway through. None of that shows in a demo, and all of it shows the week after launch.
The five things I find every time
API keys and secrets in client-side code. Anything shipped to the browser can be read, so a Stripe secret key or a service role key in there is not hidden, it is published.
No row level security on the database. In Supabase the public key is meant to be public, and policies are what stop one user reading every other user's rows. New projects often start with tables open, and generated code rarely adds the policies. Firebase security rules are the same story in a different syntax.
Authentication checked only in the interface. Hiding a button does not protect anything. If the check is not enforced on the server or in the database, anyone can call the endpoint directly.
No backups and no error tracking. When something breaks you find out from a customer, and there is nothing to restore.
Input going straight into queries or prompts without validation. That is how you get SQL injection, and its newer equivalent where user text rewrites what your AI feature was told to do.
| Gap | What it means in practice | Fix |
|---|---|---|
| Secrets in client code | Anyone can read your API keys from the browser | Move to server-side environment variables, rotate the keys |
| No row level security | Any logged-in user can query everyone else's rows | Write Postgres RLS policies, or Firebase security rules |
| Auth checked in the UI only | Hiding a button protects nothing; the endpoint is still open | Enforce on the server and in the database |
| No backups or error tracking | You learn it broke from a customer, with nothing to restore | Automated backups plus an error reporting service |
| Unvalidated input | SQL injection, and prompt injection in AI features | Validate and parameterise everything crossing the boundary |
Usually worth rescuing
The first thing I do is look at what exists and tell you whether it is a rescue or a rebuild. Most of the time it is a rescue.
The work you did defining what the app should do is the valuable part and it survives. The screens generally survive too, often ported into Next.js so they render fast and can be maintained. What gets rebuilt is the data model, the access rules, payments and deployment.
Sometimes it genuinely is a rebuild, and I will say so plainly rather than patching something that fails in three months and costs more.
Why I am useful on this specifically
I use the same tools daily. I know where they are strong and exactly where they stop. So I am neither precious about generated code nor mystified by it, and I am not going to charge you to rewrite work that is already fine.
I also follow this area properly. Models, agents, automation that runs a business process overnight, hardware and printing in the corner of the studio. Not because it is my industry, but because it is the most interesting thing happening right now, and it means the advice you get is current rather than from a course taken in 2021.
Where this is going
More people will build their own first version, and that is good. More ideas get tested and fewer get talked out of existence in a meeting.
It moves where the expertise sits. Less typing code, more knowing what is missing, what is unsafe, and what will not survive contact with real users. If you have built something and hit a wall, get it checked before someone quotes you to bin it and start again.
Built something with AI and stuck before launch? Send it over and I will tell you what is missing and whether it is worth saving.
Get it checkedStraight answers
- Can you fix an app built with Lovable, Bolt or v0?
- Yes, that is a service in its own right. I assess what exists, keep what is worth keeping, and rebuild the parts that will not survive real users. Most of the time it is a rescue rather than a fresh start.
- Is AI generated code safe to put live?
- Not without a review. The recurring problems are API keys left in client-side code, databases with no row level security, authentication that works but is not enforced on the server, and no backups. All fixable, none obvious unless you know to look.
- What is row level security and why does it matter?
- In Supabase or any Postgres backend, row level security policies decide which rows each logged in user can read or change. The key in your browser code is public by design, so without policies anyone can query the whole table. Firebase has the equivalent in its security rules.
- Will I have to start again?
- Usually not. The product thinking and most of the screens carry over. What gets rebuilt is the data layer, authentication and deployment, which is the part you were never going to enjoy.