The pre-launch checklist for AI-built apps

  • September 5, 2026
  • Aditya Tyagi

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)

  1. Row Level Security is enabled on every table that holds anything real.
  2. Each policy checks ownership, not merely that the user is signed in.
  3. Signing up as a second user and changing an ID in the URL does not reveal the first user's data.
  4. No table is left world-readable "temporarily".
  5. The service_role key appears nowhere in your front-end.
  6. Storage buckets have access rules too — this one is missed almost every time.

Secrets

  1. Searching the loaded JavaScript for sk_, secret, service_role and api_key returns nothing unexpected.
  2. Every key that should be server-side is called through your own API route or edge function.
  3. No key is committed to your repository, including in its history.
  4. Any key that was ever public has been rotated, not just moved.

Authentication and permissions

  1. Logging out and pasting a logged-in URL into a private window does not load the page.
  2. Admin routes are refused by the server, not merely hidden in the interface.
  3. Roles are read from the database on each request, not from a value held in the browser.
  4. Password reset and email verification work end to end, from a real inbox.
  5. Sessions expire, and logging out actually invalidates the session.

Deployment

  1. The app builds and runs on a host you control, not only in the tool's preview.
  2. Every environment variable is set on that host, and you have the complete list written down.
  3. Your custom domain is connected and HTTPS is working.
  4. Pushing a change deploys it, without a manual ritual only one person knows.
  5. Database connections are pooled, so traffic does not exhaust the connection limit.

When things go wrong

  1. A failed request shows the user something, rather than a blank screen.
  2. Errors are recorded somewhere you will actually look.
  3. 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