The pre-launch checklist for AI-built apps
Before launching an AI-built app, check four categories: database access rules are enabled and check ownership rather than just authentication; no secret keys are readable in the browser; routes and permissions are enforced on the server; and the app deploys and runs somewhere you control. Most of these take under a minute to verify.
Part of the guide to shipping an app built with an AI coding tool.
Access to your data (do these first)
- Row Level Security is enabled on every table that holds anything real.
- Each policy checks ownership, not merely that the user is signed in.
- Signing up as a second user and changing an ID in the URL does not reveal the first user's data.
- No table is left world-readable "temporarily".
- The service_role key appears nowhere in your front-end.
- Storage buckets have access rules too — this one is missed almost every time.
Secrets
- Searching the loaded JavaScript for sk_, secret, service_role and api_key returns nothing unexpected.
- Every key that should be server-side is called through your own API route or edge function.
- No key is committed to your repository, including in its history.
- Any key that was ever public has been rotated, not just moved.
Authentication and permissions
- Logging out and pasting a logged-in URL into a private window does not load the page.
- Admin routes are refused by the server, not merely hidden in the interface.
- Roles are read from the database on each request, not from a value held in the browser.
- Password reset and email verification work end to end, from a real inbox.
- Sessions expire, and logging out actually invalidates the session.
Deployment
- The app builds and runs on a host you control, not only in the tool's preview.
- Every environment variable is set on that host, and you have the complete list written down.
- Your custom domain is connected and HTTPS is working.
- Pushing a change deploys it, without a manual ritual only one person knows.
- Database connections are pooled, so traffic does not exhaust the connection limit.
When things go wrong
- A failed request shows the user something, rather than a blank screen.
- Errors are recorded somewhere you will actually look.
- You have a database backup, and you have restored from it once to confirm it works.
A backup you have never restored is not a backup. It is an assumption.
If several of these fail
That is normal and it is not a reflection on you. These tools stop at the same boundary every time, because generating a working demo and configuring a system strangers can use are different problems, and only the first one is automated.
Work top-down. The data access checks are the ones where being wrong has consequences you cannot undo — everything below them is recoverable.
Want someone to look at yours?
Send us the repo or the live URL. You get a written list of what is broken, what each fix costs and what can wait — back within 24 hours, and yours to keep either way.
Get a $99 audit