Your app was built with AI. Here's how I make it safe to launch

Most apps built with AI tools work in a demo and hide the same five or six problems. The good news is that they're usually fixable without starting again.

I see a lot of these now. Founders build something real in Lovable, Bolt, Replit or Cursor, show it to customers, and then ask the right question before launch: is this actually safe? Often it isn't, yet. Here's how I get it there.

Why do AI-built apps look finished when they aren't?

Because AI tools are judged on what you can see. You ask for a dashboard, you get a dashboard. You click around, it works, you move on.

The parts that make an app safe don't show up on screen. Does the server check that this user is allowed to see this record? What happens when someone sends a form with a script in it? Where's the API key stored? You never asked for those, so you often didn't get them. One large Veracode study found 45% of AI-generated code samples failed security tests.

What do I usually find?

The same list, in roughly the same order of how much damage it can do.

Question	What it looks like	What can go wrong
No server-side permission checks	The screen hides other people's data, but the API still returns it	Any user can read or change any other user's records
Secrets in the code	API keys and passwords written straight into files	Anyone with the code, or the browser, can use your accounts
Wide-open database rules	Rules set to allow everything while building	Your whole database can be read from the outside
Outdated or made-up packages	Libraries that are old, or names the AI invented	Known security holes, or an attacker publishing a package with that name
Inputs taken on trust	Forms and URLs passed straight to the database or page	Data stolen or pages hijacked through a crafted input
No tests	Nothing checks that features still work after a change	Every fix risks breaking sign-in or payments

The first row is the one that worries me most, because it's invisible from the front end. The app looks fine. Then someone opens the browser's developer tools, changes a number in a request, and sees a stranger's invoices.

What order do I fix it in?

Whatever could hurt you most, first. Tidying the code comes last.

1. 01ReviewRead the code, run it, write down what's there
2. ↓→
   02Close the holesPermissions, secrets, database rules
3. ↓→
   03Add testsSign-in, payments and the main flows
4. ↓→
   04Clean upPackages, structure, error handling
5. ↓→
   05LaunchWith monitoring, so you see problems first

The review is written in plain English and ranked by risk. You keep it whether or not I do the fixes. Most founders want to know what they're dealing with before they decide anything, and they should.

Should you fix it or start again?

Fix it, most of the time. An AI-built app usually has a sound shape and a handful of serious holes. Starting again throws away everything that works and takes months you probably don't have.

I'll suggest a rewrite only when the review shows something structural: a data model that can't support what the business needs, or an app so tangled that every fix breaks two other things. If that's the case, I'll show you why in the review, not just say it.

Can you keep using AI tools after the rescue?

Yes, and you probably should. They're fast. The trick is putting guard rails around them, so the next feature doesn't bring back the problems you just paid to fix.

• Tests that must pass before any change goes live, whoever wrote it.
• Instructions in the repo that tell the AI how your app handles permissions, secrets and data.
• A person reviewing anything that touches sign-in, payments or the database rules.

Is your app ready to launch?

1. Could a logged-in user see another user's data by changing a number in the URL or a request?Yes →Fix this first. Add permission checks on the server for every request.No ↓
2. Are any API keys or passwords written in the code?Yes →Move them to environment settings and change the keys today.No ↓
3. Are your database rules still set to allow everything?Yes →Lock them down before anyone else finds them.No ↓
4. Would you have no way to know if a change broke sign-in or payments?Yes →Add tests for those two flows before you add anything else.No ↓
5. Has nobody but the AI read the code?Yes →Get a review before launch. It's far cheaper than a breach.
6. Still no →You've covered the basics. A second pair of eyes before launch is still worth it.

If you've built something with AI and want to launch it without the worry, that's what my code rescue service is for. Or send me a short brief with what you built and what it's built on.