The launch checklist for Lovable and Supabase apps

Your Lovable or Bolt app works in the demo. Before real people sign up and trust it with their data, run through this list. It's the same order I use in a diagnostic: the items that leak data come first, the ones that just hurt come last.

1. Data access

• RLS is on for every table in public. In the Supabase dashboard, any table marked “RLS disabled” can be read by anyone with your public key, which ships in your frontend by design.
• Every table has policies that match who should see what. A policy of using (true) is the same as no policy. Look for auth.uid() = user_id or a membership check.
• New tables get explicit grants. From Oct 30, 2026, Supabase stops granting them automatically on existing projects. See the Oct 30 grants change.
• Storage buckets aren't public unless they need to be. Profile photos, maybe. Invoices and uploads, no.
• Test as a second user. Sign up with another email and try to load the first user's records by ID. This one test catches most leaks.

2. Keys and secrets

• No service_role or secret key in the browser. Search your built JavaScript for service_role and sb_secret_. See anon key vs service_role key.
• Third-party keys (OpenAI, Stripe secret, Resend) live in server-side env vars or Edge Function secrets, never in client code.
• Any key that was ever committed or shipped to the browser gets rotated, not just deleted from the code. Git history and CDN caches keep it.

3. Auth

• Email confirmation is on, or you've decided on purpose that it's off.
• Redirect URLs list only your real domains, not * or a preview URL.
• Roles such as admin are stored server-side, not in a field the user can update.
• Password reset works end to end on your real domain.

4. Deploys and environments

• The production build runs from a clean checkout, not just in the builder's preview.
• Env vars are set in your host (Vercel, Netlify, Cloudflare) for production, not only locally.
• You have a staging project, or at least a branch database, for testing schema changes.
• Your custom domain has HTTPS and redirects www to the canonical domain (or the other way round).

5. Backups

• You know what your Supabase plan backs up and how far back you can restore.
• You've actually restored a backup once, into a scratch project. An untested backup is a guess.
• Destructive migrations (drop, rename, type changes) go through review first.

6. Monitoring

• Frontend and Edge Function errors go to an error tracker that emails or pings you.
• An uptime check hits your app and one API route every few minutes.
• You get an alert before your Supabase or AI-provider usage hits a plan limit.

7. Cost guardrails

• Spend caps or budget alerts are set on every paid API.
• Any AI call a user can trigger has a per-user rate limit, so one script can't drain your account overnight.

If you only do three things

1. Turn on RLS and write owner policies for every table.
2. Make sure no secret key is in your frontend, and rotate any that ever was.
3. Set up error alerts so you hear about problems before your users do.

Want a second pair of eyes? The Launch Risk Diagnostic runs this whole list against your app with read-only access and gives you a ranked report and a fixed quote in 2 business days.