Free checklist · print it or save it as a PDF

12 checks before you launch an AI-built app

AI app builders write working demos fast. These are the twelve places where the demo and a safe production app most often differ. Most checks take a few minutes, and you do not need to be an engineer for the first pass.

Secrets and data

1. No secret keys in the browser

   Check: open your live site, view the page source and the loaded JavaScript, and search for sk_live, sk_test, service_role and sk-. In the code, look at every variable starting with VITE_ or NEXT_PUBLIC_.

   Why: anything with those prefixes is published to every visitor. Only publishable or anonymous keys belong there. A leaked secret key must be rotated, not just removed.

2. Row-level security is on, with real policies

   Check: in Supabase, open each table and confirm RLS is enabled. Then read the policies. A policy of using (true) lets everyone through.

   Why: the anonymous key is public by design. Without policies tied to auth.uid(), any visitor can read or change any row.

3. One user cannot open another user's records

   Check: sign in as user A, copy the address of one of your records, sign in as user B and paste it. Do the same with an ID in an API request.

   Why: if B can see it, ownership is only checked in the interface.

4. File storage is private by default

   Check: open an uploaded file's link in a private browser window. See whether you can upload any file type and any size.

   Why: public buckets expose customer uploads, and open uploads get abused for hosting.

Login and payments

1. The server checks who is asking

   Check: sign out, then call one of your API routes or edge functions directly from a private window or with curl.

   Why: hiding a button is not access control. Every route that reads or writes private data must verify the session itself.

2. Stripe webhooks are verified

   Check: find the webhook handler and look for constructEvent with your signing secret. Confirm the endpoint is registered in the Stripe dashboard for live mode.

   Why: without signature checks, anyone can post a fake payment event and unlock paid features.

3. Access is granted by the webhook, not the success page

   Check: pay in test mode, then close the tab before the redirect. See whether the account still upgrades. Then visit the success URL without paying.

   Why: redirects fail and can be faked. The webhook is the only reliable signal, and it can arrive twice, so handling must be safe to repeat.

4. Prices and roles are never trusted from the browser

   Check: look at what the checkout or signup request sends. If it includes an amount, a plan price or a role such as admin, try changing it.

   Why: the server should look these up itself.

Running in production

1. Costly endpoints have limits

   Check: find every route that calls an AI model, sends email or sends SMS. Confirm it requires login and has a rate limit.

   Why: an open AI endpoint is free compute for strangers, billed to you.

2. Test and live are separate

   Check: confirm production uses live Stripe keys and its own database, and that password reset and login links point to your real domain, not localhost or a preview address.

   Why: mixed environments cause the failures that only real customers find.

3. You can undo a bad day

   Check: confirm database backups are on and that you know how to restore one. Confirm schema changes live in migration files, not only in dashboard clicks. Add error tracking.

   Why: one bad prompt can drop a column. Without backups and migrations there is no way back.

4. The dependencies are real and pinned

   Check: confirm a lockfile is committed. Look up any package you do not recognize and check it is the well-known one, with recent releases.

   Why: AI tools sometimes add packages that are abandoned, misnamed or invented.