AI coding tools are very good at getting you to something that works. They are much less reliable at the things you can't see in a demo: who is allowed to read which data, where your secret keys ended up, and what happens when a payment fails.
This checklist covers those things. It's written for founders who built most of their product with an AI tool and are about to put it in front of real users. Most checks take a few minutes and need no coding. Where a check is technical, it says exactly what to look for.
If you only have an hour
Do these five first. They are the ones that turn into leaked data or lost money:
- No secret keys in the browser (check 1)
- One user can't see another user's data (check 7)
- Database access rules are switched on (check 9)
- Paid features are unlocked by your server, not by the browser (check 15)
- Spending limits on your AI and API accounts (check 18)
1. Secrets and API keys
- 1. No secret keys in the browser. Open your live app, open the browser's developer tools, and search the loaded files for
sk_live,service_role, and the first few characters of each secret key you use. Anything in a variable starting withNEXT_PUBLIC_orVITE_is sent to every visitor. Publishable keys (Stripe'spk_key, Supabase's anon key) are meant to be public. Secret keys are not. - 2. No secrets in your repository. Search your code for the same keys. Check that
.envfiles are listed in.gitignoreand were never committed. - 3. Every exposed key has been replaced. If a key was ever in the browser, in your repository, or pasted into a chat, deleting it from the code is not enough. Generate a new one in the provider's dashboard and revoke the old one.
- 4. Test and production use different keys. Your live site should use live keys, and everything else should use test keys, so a mistake during development can't touch real customers.
2. Accounts and access
- 5. Pages that need a login actually require one. Copy the address of a page from inside your app, open a private browser window, and paste it. You should be sent to the login page, not shown the content.
- 6. Your API checks who is calling. Hiding a button is not security. Every server route that reads or changes data must check the logged-in user itself, because anyone can call it directly without your interface.
- 7. One user can't see another user's data. Create two accounts. As user A, open one of your own items and copy its address or ID. Log in as user B and open that address. If B can see or edit A's item, you have the most common serious bug in AI-built apps.
- 8. Admin powers are checked on the server. If you have an admin area, confirm a normal account can't reach it by typing the address, and that admin actions are refused for non-admins on the server.
3. Your database
- 9. Access rules are switched on for every table. On Supabase, every table needs Row Level Security enabled, with policies that say who can read and write each row. A table with it disabled can be read and changed by anyone who has your public key, which is every visitor. On Firebase, make sure your rules are not still in test mode (
allow read, write: if true). For Supabase, here is a 10-minute walkthrough. - 10. File storage is private unless it's meant to be public. Uploaded documents, invoices, and profile data should not be reachable by guessing a link.
- 11. Backups exist, and you have restored one. Check whether your hosting plan includes automatic backups; some free plans don't. Then restore one into a test project once. A backup you have never restored is a hope, not a backup.
- 12. Development and production are separate databases. If your AI tool is connected to the same database your customers use, one bad instruction can delete real data.
4. Payments
- 13. Live mode is on in production, and only there. Make one real purchase with your own card on the live site, then refund it.
- 14. Payment notifications are verified. Stripe and other providers tell your server about payments through webhooks. Your server must check the signature on each one. Otherwise anyone can send a fake "payment succeeded" message.
- 15. Paid features are unlocked by your server. Access should be granted when your server receives the verified webhook, not when the browser lands on a "thank you" page. Try opening the success page directly without paying.
- 16. Failed payments, cancellations, and refunds are handled. Cancel a test subscription and let a test card fail on renewal. Check that access ends when it should and continues when it should.
5. Abuse and runaway costs
- 17. Rate limits on anything expensive. Signup, login, password reset, and any feature that calls an AI model or a paid API should limit how often one person can use it.
- 18. Spending limits on your AI and API accounts. Set a monthly cap and a billing alert in each provider's dashboard. Without one, a bug or a bored stranger can run up a large bill overnight.
- 19. Input is checked on the server. Limit the size and type of file uploads and the length of text fields on the server, not only in the form.
- 20. Public forms have bot protection. Signup and contact forms without it tend to fill with spam within days of going live.
6. Knowing when it breaks
- 21. Error tracking is installed. Use a tool such as Sentry so you hear about errors from the tool, not from an annoyed customer.
- 22. Something checks that the site is up. A free uptime monitor that emails or texts you is enough.
- 23. You can undo a bad release. Know how to roll back to the previous version on your hosting platform, and try it once before launch day.
- 24. Dependencies have no known serious vulnerabilities. Run
npm audit(or your language's equivalent) and update anything marked high or critical.
7. Domain and email
- 25. Your own domain, with HTTPS everywhere. Both the
wwwand non-wwwversions should work and lead to the same place. - 26. Your sending domain is authenticated. Set up SPF, DKIM, and DMARC records for the domain your app sends email from. Without them, your emails are likely to land in spam.
- 27. Account emails actually arrive. Send yourself a signup confirmation and a password reset at a Gmail address and an Outlook address, and check the links in them work.
8. Legal and trust basics
This isn't legal advice, but these are the things users and payment providers expect to see.
- 28. A privacy policy and terms that match what the app does. They should name the data you collect and the services you send it to, including any AI provider.
- 29. Cookie consent if you track visitors in the EU or UK. Analytics and advertising cookies generally need consent before they load.
- 30. Users can delete their account and data. Either a button in the app or a clearly stated email address that you actually monitor.
9. The final run-through
- 31. The whole journey works on a fresh account, on a phone. Sign up, verify, pay, use the main feature, log out, reset your password. Use a device and an email address your app has never seen.
- 32. Analytics are in place. You should be able to answer "how many people signed up, and how many did the main thing" on day one.
- 33. Users can reach you. A support email or a feedback form, visible in the app. Early users who hit a problem and can't tell you just leave.
What this checklist can't tell you
A checklist finds the problems you know to look for. It won't catch the access check that's missing on one route out of forty, or the database policy that looks right and isn't. Asking the AI tool that wrote the code to review it helps, but it tends to miss the same things twice.
If you'd like an engineer to go through your app before you launch, that's what the launch-readiness audit is for: a fixed-price review of everything above, with findings ranked by severity and fix instructions you can paste straight into your AI tool. Or get in touch and tell me what you've built.