The launch readiness checklist for AI-built products

You built it with Lovable, Replit, Bolt or an agency, it works, and people are asking for access. Before you say yes, there are five controls worth checking. None of them need you to read code. Each has a question you can answer today and a check someone technical can run in an hour.

This is the same list a CTO runs before a launch. The order matters: the first items are the ones that end up in the news.

1. Is one customer's data separated from another's?

Most AI builders ship on Supabase or Firebase. Both are good databases, and both default to a mode where any signed-in user can read any row unless someone writes the rules that say otherwise. In Supabase those rules are called row-level security (RLS) policies; in Firebase they are security rules.

A scan by a Replit employee in 2026 found 170 of 1,645 featured Lovable apps leaking user data this way. The apps worked. The builders were happy. The database was open.

The question: has a person who can read the policies confirmed that a user can only see their own rows?

The check: sign in as two test users and try to fetch the other user's records straight from the API, not through the app's screens. If it comes back, you are not ready.

2. Does sign-in go through a known provider?

Auth is the one thing you should never let an AI improvise. Supabase Auth, Firebase Auth, Clerk and Auth0 are all fine. A hand-rolled table of emails and passwords is not, and neither is "we check the email on the client".

The question: which provider handles sign-in, and who can reset or revoke an account?

The check: try to use the app with the sign-in step skipped (open a protected page in a private window). If it loads, the pages are not actually protected.

3. Are there secrets in the bundle?

When you paste an API key into a prompt so the builder can "connect to Stripe", that key often ends up in the JavaScript sent to every visitor's browser. Anyone can open the developer tools and read it.

The question: which keys ship inside the app, and what could someone do with them?

The check: build the app for production and search the output for the prefixes your providers use: sk_live, AIza, service_role. Anything that is not a public key belongs on a server.

4. Can you restore a backup?

Supabase and Firebase keep backups on paid plans, but a backup you have never restored is a hope. Deleting a table through the builder's chat is one sentence away.

The question: when did you last restore a backup, and how long did it take?

The check: restore the latest backup into a scratch project. Time it. Write the steps down. If it takes a day, you now know your recovery time.

5. Who owns the domain and the accounts?

The domain, the hosting account, the database project, the Apple and Google developer accounts and the payment provider should be in your name, with contractors invited as members. The pattern behind most "my developer disappeared" stories is an account the founder never had.

The question: which accounts are not in my name, and what happens if that person leaves?

The check: list every account the product depends on and who the owner is. Transfer anything that is not you. Then export the source code to a repository you own, even if you never open it.

What to do with the result

If all five pass, launch. If any fail, fix them in this order: data isolation, auth, secrets, backups, ownership. The first three are the ones that put you in a headline; the last two are the ones that put you out of business quietly.

A Launch Readiness Check is exactly this list, run by a person who reads the code and writes down the verdict. It is cheaper than the incident.