Why your AI-built app keeps breaking, and what to fix first
On this page
An AI-built app keeps breaking because the tool that wrote it was aiming for a demo that works, and nobody checked the parts a demo never touches. Fix what can leak first, the secrets and the database rules, then login, then the integrations, and leave new features until all of that holds.
That's the short answer. The rest of this post is the order I work through when a founder sends me an app built with Lovable, Bolt, Replit, Cursor, v0 or Base44, and why each step comes where it does.
What the demo never tested#
A demo runs on one account, with test data, on a good connection, with the person who built it clicking the buttons in the right order. Real users do none of that. They sign up with the same email twice, open two tabs, paste a paragraph into a field meant for a name and come back a week later expecting their data to still be theirs.
The code AI tools write is usually fine at the demo and weak exactly where real use starts. Veracode tested more than 100 AI models on 80 coding tasks and found security flaws in 45% of the code they wrote, and the newer, larger models didn't do better (Veracode's 2025 GenAI Code Security Report). The flaws fall into the OWASP Top 10, the standard list of the ways web apps get broken into, which is why that list is the right place to start checking.
Most founders only find out after a breach, an exposed database, or users losing trust overnight. The checklist below is meant to get you there first.
What to fix first#
The order matters more than the list. Anything that can leak goes first, because a leak can't be undone. Anything that can lose you a paying customer goes next. Polish goes last.
1. Secrets in the code#
API keys for OpenAI, Stripe or your database end up pasted into the frontend, or committed to the repo, because that's the quickest way to make the demo work. Anyone who opens the browser's developer tools can copy a key that ships in the frontend.
Move every key to a server-side environment variable, then rotate every key that was ever exposed. Check the git history as well, because a key deleted in the latest commit is still sitting in the ones before it.
2. The database rules#
This is the one that turns into a headline. Supabase row-level security gets switched off to make a query work, or Firebase rules get left public, and the app runs fine because every user can read every row, including everyone else's.
Turn the rules on, write a policy for each table that says who can read and write which rows, and then test it the way an attacker would, logged in as one user and asking for another user's data.
3. Login, and who can see what#
AI-written auth often hides a button without checking anything on the server. The page looks locked, and the API behind it answers anyone who asks.
Every route that reads or changes data should check the session on the server, and check that this user is allowed to touch this record. While you're there, try the password reset and the sign-up flow with an email that already exists, because that's where auth bypasses tend to hide.
4. Injection and cross-site scripting#
Anywhere text from a user reaches a database query, or gets rendered back onto a page as HTML, is a way in. Use the parameterised queries your database library already gives you, let the framework escape what it displays, and be suspicious of any code that builds a query or a chunk of HTML by gluing strings together.
5. Integrations that only work in test#
Stripe still in test mode, webhooks that nobody verifies, an OpenAI call with no timeout and no spending limit. All of them work in the demo and fail, or run up a bill, the first week real traffic arrives.
Walk each integration through production. Verify webhook signatures, handle the payment that fails as well as the one that succeeds, and put timeouts and limits on every call to a paid API.
6. Dependencies, dead code and debug logs#
AI tools install packages freely and leave behind code nobody calls. Run a dependency scan, remove what isn't used, and strip out the debug logs, especially any that print user data or tokens to the console.
7. Deployment and monitoring#
Deploy to Vercel, Railway or your own server with error monitoring and uptime alerts switched on, so that when something breaks you hear about it before your users tell you.
What can wait#
A redesign, performance tuning and the next feature can all wait until the seven steps above hold. It's tempting to keep prompting the tool that built the app for new features, and every new feature built on top of an open database is one more thing to fix later.
When to get help with it#
If you're not a developer, you can't tell yet whether the build is any good, and that's a normal place to be. You shouldn't have to become a developer to know whether your product works.
This is the checklist I work through when a founder hands me an AI-built app. I audit it against the OWASP Top 10, write down what I found and what I changed, fix it, get it live for real users and then stay to keep it running. If you'd rather hand yours over, send me your repo and I'll tell you honestly what's broken and what it'll take. More on how that works is on the vibe-coded app page.