Is your AI-built app safe to launch? A checklist for non-developers.
At some point between “this works” and “people are using this”, a reasonable worry shows up: you are about to accept other people’s email addresses, passwords, maybe card details — running through code you did not write and cannot fully read.
That worry is appropriate. Not alarming, but appropriate. AI tools produce working software readily; they do not reliably produce safe software unless asked, and they will not volunteer that something is unsafe.
You do not need to read the code to check most of what matters. Here is what I look at first.
1. Are your secret keys in your code?
The most common serious mistake, and the most damaging.
Your app uses keys for its database, email service, payment provider. If any of those are written directly into your code — rather than stored as environment variables — then anyone who views your site can potentially find them.
How to check: search your whole project for key, secret, token, and password. You are looking for long random-looking strings sitting in plain sight. Ask your AI tool: “Are there any API keys, tokens or secrets written directly in this codebase rather than stored as environment variables?”
Why it matters: exposed keys are harvested automatically, within minutes, by bots that scan public code continuously. People have woken up to five-figure bills from keys committed by accident. If you find one, replacing it is not enough — you must revoke the old key at the provider, because it is already out.
2. Can users see each other’s data?
The most dangerous flaw, and the least visible.
If your app stores anything per-user — saved items, messages, orders — something must enforce that user A cannot fetch user B’s records. AI-generated apps frequently display only your own data while the underlying database will happily hand over anyone’s if asked directly.
How to check: if you use Supabase or Firebase, ask: “Is Row Level Security enabled on every table, and does each table have a policy restricting access to the row owner?” If the answer is no, or vague, that is your top priority before launch.
Why it matters: it does not require an attacker. A curious user changing a number in a URL is enough. And a data leak involving other people’s information is a different category of problem to a broken feature — it is the kind that ends the project.
3. Is anything sensitive being decided in the browser?
Anything running in the visitor’s browser can be altered by that visitor. Always.
If your app decides in the browser whether someone is an admin, whether they have paid, or what a price is, then someone can change that decision. Not hypothetically — the tools are built into every browser.
How to check: ask “Are there any permission, pricing or access decisions made in client-side code rather than verified on the server?”
Why it matters: this is how people get free subscriptions and unauthorised admin access. The browser is a suggestion box, not an authority.
4. Are you storing passwords yourself?
If your app has its own sign-up and you built the password handling with AI, look closely.
How to check: ask directly — “How are user passwords stored? Are they hashed, and with what?” If the answer mentions storing them as text, or encryption that can be reversed, stop and fix it.
The better answer: do not store passwords at all. Use a service that handles it — Supabase Auth, Clerk, Auth0, or sign-in with Google. Password handling has a great many subtle requirements, and getting it slightly wrong is worse than not doing it. This is one of the few places where “use the boring existing thing” is unambiguously right.
5. Can someone submit anything they like?
Every input box is somewhere a stranger can type. Some will type things you did not anticipate — a hundred thousand characters, code, database commands.
How to check: ask “Is user input validated on the server, or only in the browser? Are database queries parameterised?”
Why it matters: browser-side validation is a courtesy to honest users, not a defence. It is trivially bypassed. The server must check again.
6. Does anything stop someone hammering it?
If your app sends emails, calls a paid API, or runs anything expensive, ask what happens if someone triggers it a thousand times a minute.
Without rate limiting the answer is usually “it runs a thousand times a minute, and you pay”. This is one of the more common ways small apps generate surprise bills — often not maliciously, just a bot probing everything it finds.
7. What happens when it goes wrong?
Error messages meant for developers frequently reveal more than they should — file paths, database structure, occasionally keys. Fine while building; a map for anyone probing once you are live.
How to check: ask “Are detailed error messages shown to users in production, or only logged on the server?” Users should see “something went wrong”. You should get the detail.
How worried should you actually be?
Depends entirely on what you are holding.
A tool that stores nothing personal and takes no payments — the stakes are low. Launch it, learn from real use.
An app holding other people’s data, or taking money, is a different matter. Numbers 1, 2 and 4 above are not optional there, and they are worth a proper look from someone who can read the code before you invite anyone in.
The honest summary: AI tools have made building genuinely easy. They have not made judgement easy, and security is almost entirely judgement — knowing which questions to ask, and recognising a hand-waving answer. That gap is real, and it is not a reflection of your ability.
Want a straight answer on yours? A session will get you an honest read on whether it is safe to launch, and the fixes if it is not. If it is fine, I will tell you that too.