The launch checklist for apps built with AI

Start with the free check

Part of this list can be read from the outside, without access to your code. The free launch check does that part in about ten seconds: secret keys in the page and its scripts, HTTPS and the security certificate, your domain’s expiry date, browser security settings, link previews, the phone layout and how fast the app answers. Run it first, then work through the rest.

1. No secret keys in the browser

Anything your app’s pages can read, every visitor can read. A Stripe secret key (sk_live_…), a Supabase service-role key or an OpenAI key in that code is a key you have given away. Publishable keys (Stripe’s pk_, Supabase’s anon or publishable key, Firebase’s web config) are meant to be public; the others never are.

Check it: the free check scans for them. Or open your live app, open the developer tools (right-click, Inspect), search all files for sk_live, service_role and sk-.

Found one? Revoke it before anything else. How to check, rotate and move keys server-side.

2. Database rules that let each person see only their own data

With Supabase, every table needs row-level security switched on and a policy for each thing people may do: read, add, change, delete. With Firebase, the rules must not still be in “test mode”, which lets anyone read and write everything until the date it was set to expire.

Check it: sign up a second account in a private window and try to see the first account’s data. If you can, so can anyone. Then try a normal save as the second account: if it fails, a policy is missing.

Related: a save Supabase refuses, lists that come back empty, Firebase permission errors.

3. Every environment variable in production

The preview has your keys and addresses. Your host builds the app again with its own set, and anything missing there is empty on the live site. A variable is baked in when the app is built, so adding one means deploying again.

Check it: compare your host’s Production variables with your builder’s, name by name. Then open the live app with the browser console open and look for red errors such as “supabaseUrl is required”.

Related: works in the preview, blank in production.

4. Sign-in that ends on your live domain

Your sign-in provider keeps its own list of addresses it may send people back to. It was filled in while you were building, so it often still points at the preview or localhost.

Check it: on the live domain, in a private window, sign up, confirm the email, sign out, sign in, and reset the password. Every step should end on your live domain.

Related: sign-in sends people to the preview.

5. Emails that reach real people

Supabase’s built-in email sender is for testing: its docs say it delivers only to your own team’s addresses, about two messages an hour. Sign-up confirmations and password resets to anyone else fail. Before launch, connect your own sender (any SMTP provider) and verify your domain with it, so mail lands in the inbox instead of spam.

Check it: sign up with an address that isn’t yours, a friend’s or a second account at another provider, and see whether the email arrives.

6. Payments in live mode, end to end

Test mode and live mode in Stripe are separate worlds: separate keys, separate prices, separate webhooks with their own signing secret. The usual launch-day failure is a live key with a test price, or a payment that succeeds while the account never upgrades because the live webhook was never set up.

Check it: buy your own product with a real card on the live site, confirm the account upgraded, then refund yourself.

Related: “No such price … exists in test mode”, paid but not upgraded.

7. Pages that survive a refresh

Clicking around works; opening a shared link to an inner page, or refreshing it, can return your host’s 404 instead.

Check it: go to any inner page of the live app and press refresh. Related: a 404 on refresh.

8. A real phone

Most people will open your link on a phone, many inside the app they found it in (Instagram, Reddit, LinkedIn), whose built-in browser is stricter than Safari or Chrome. Google sign-in, for one, refuses to run there.

Check it: send yourself the link in a messaging app and open it from there. Sign up, use the main feature, pay.

9. Link previews

When someone shares your link, the preview card comes from a few tags in your page’s head: title, description, image. Without them the share is a bare address, and people click it less.

Check it: the free check reads them. Or paste your link into a chat with yourself and look at the card.

10. A way back

Something will break the day you change something. Know before then how to put the last working version back: your builder’s version history, or your host’s list of previous deploys (Vercel and Netlify both restore one in a click). Know where your database’s backups are, and what your plan includes.

11. Someone watching after launch

The errors that matter happen in your visitors’ browsers, on their devices, at 2 a.m. Most people who hit one don’t write to you. They leave. Before launch, set up three things:

• Error monitoring, so a visitor’s error reaches you with what they were doing. The options compared.
• Uptime checks, so you know the app is down before a customer does, and why. What to do when it is.
• A status page you can point people to when something is wrong.

Vigilia does all three in one script tag, free for one app: it explains each problem in plain language, gives your AI the fix, and confirms the fix held with real visitors.

Hand the whole list to your AI

Paste this into Lovable, Bolt, Cursor or Claude Code and let it do the code-side checks for you. It will still need you for the dashboards (Supabase, Stripe, your host).

Before I launch this app to real users, review it for these problems and report what you find. Don't change anything yet; list each finding with the file and what you would change.

1. Secret keys (Stripe sk_, Supabase service_role or sb_secret_, OpenAI, Anthropic, any other API secret) anywhere in code that runs in the browser, including environment variables with a VITE_ or NEXT_PUBLIC_ prefix.
2. Calls to OpenAI, Anthropic or other paid APIs made from the browser instead of from a backend function.
3. Supabase tables without row-level security, or without a policy for SELECT, INSERT, UPDATE and DELETE. Show the policies you'd add.
4. Sign-in redirect addresses that are hard-coded to a preview URL or localhost instead of window.location.origin.
5. Stripe: whether a webhook updates the user's plan after payment, and whether it checks the signature.
6. Pages that would 404 on refresh with my host, and the rewrite rule that fixes it.
7. Missing title, description and og:image tags, and a missing viewport tag.

End with the order you'd fix them in, most dangerous first.

Read next

• Is your app leaking secret keys?
• Your app is down: what to check, in order
• The error library

Questions