I built my app with AI: is it safe to launch?
The short answer: It can be, but don't assume it is. AI app builders are brilliant for getting something working quickly, and the same few security gaps keep turning up in what they produce: databases anyone can read, secret keys visible in the browser, and missing checks on who can do what. Check those before you put real customer data in it.
Built something with AI? Great for getting started. Tools like Lovable, Bolt, Replit and v0 let people with an idea build a working app in days rather than months. That is genuinely exciting, and lots of good businesses will start this way.
When it needs to run your business, I'll make it safe, or move you onto something proven.
The catch is that "it works" and "it's safe" are different things. An app can look finished and do everything you asked, while quietly letting anyone on the internet read your customers' data. That isn't a reason not to use these tools. It's a reason to check a few things before launch.
The gaps that keep turning up
These aren't guesses. Security researchers have scanned thousands of public apps made with AI app builders, and the same problems come up again and again.
1. A database anyone can read
Many AI-built apps store their data in Supabase, a popular hosted database. Supabase protects each table with rules called Row Level Security (RLS): rules that say who can see and change which rows. If RLS isn't switched on, or the rules are too loose, anyone who finds your app can read or change the whole table, without logging in.
Supabase's own documentation puts it plainly: a table without RLS "is readable and writable by any role with a grant on it". In 2025 this exact problem was recorded as a formal security vulnerability (CVE-2025-48757) across apps built with Lovable, rated 9.3 out of 10 for severity. Lovable disputed the report, saying securing the data is each customer's responsibility, which is exactly the point: it is yours to check.
2. Secret keys in the browser
Apps talk to other services (payments, email, AI models, the database) using API keys: long passwords for software. Some of these must only ever live on a server. If one ends up in the code that runs in your customer's browser, anyone can copy it and use it as if they were you.
Supabase's service_role key is the classic example: it bypasses all the security rules, so it must never be used in the browser. One study of over 5,600 AI-built apps found more than 400 exposed secrets. See API keys in your code for more.
3. Checking who someone is, but not what they may do
An app may make people log in, then let any logged-in user see any other user's records just by changing a number in the address bar. This is the most common serious web security problem of all: "broken access control" is number one on the OWASP Top 10, the industry's list of the biggest web app risks.
4. No plan for when things go wrong
No backups you have tested, no record of who did what, and no one watching for problems. These don't stop you launching, but they decide how bad a bad day gets.
How to check your app before launch
- List where your data lives. Usually a database such as Supabase or Firebase, plus file storage.
- Check every table has security rules switched on. In Supabase, every table in an exposed schema should have RLS enabled, with rules that match who should see what. Lovable's own docs say to do this before going live.
- Look for secrets in the browser. Open your app, then your browser's developer tools, and search the loaded code for words like
key,secretandservice_role. Anything other than a deliberately public key is a problem. - Test as a stranger. Create two test accounts. Logged in as one, try to see or change the other's data. Then try without logging in at all.
- Turn on backups and test getting data back.
- Write down what the app uses: which services, which accounts, which keys, and who pays for them.
When to call someone
Call for help if:
- Real customer data, payments or anything sensitive will go through the app.
- You aren't confident checking the database rules yourself.
- The app has grown beyond what the AI tool handles well, and changes keep breaking other things.
- You want it hosted properly, on a server you control, rather than inside the builder's platform.
A health check looks at exactly these things and gives you a plain-English list of what to fix first. If it turns out the app needs rebuilding properly, I'll say so, and point you to a development partner I trust.
Sources
Want a second pair of eyes before launch?
One server reviewed, a plain-English report, prioritised fixes and a 30-minute call.