afterbuild/ops
Resource · Pre-launch checklist

How to audit an AI-built app before you launch.

A free 40-item checklist. 90 minutes of work. Catches the pre-launch failures that become post-launch incidents.

By Hyder ShahFounder · Afterbuild LabsLast updated 2026-04-15

Also see AI App Security Checklist 2026 — the current-year OWASP-aligned checklist for launching AI-generated code safely. Book a paid audit via /solutions/ai-app-security-audit.
TL;DR (55 words)

Work through these 40 checks before launch. Security (8), auth (6), payments (6), email (4), deploy (6), performance (4), observability (6). The two-user RLS test alone catches more disclosure vulnerabilities than any other single check. If five or more fail, book a diagnostic — don't ship.

By Hyder Shah · Published 2026-04-15 · Updated 2026-04-15

How to use this checklist

Set aside 90 minutes. Work through each section in order; don't skip ahead. If a check reads as jargon, flag it for a developer — don't guess. At the end, tally failures. If five or more fail, book a diagnostic before launching; fixing them all at once is cheaper than fixing them one by one post-launch.

The checks reflect patterns documented by Veracode's 2025 AI code security research, The Register's 2026 Lovable incident coverage, the Stripe benchmark on AI-built integrations, and the patterns from Afterbuild Labs's rescue engagements.

Section 1 — Security (8 checks)

  1. RLS enabled on every table containing user data (Supabase → Authentication → Policies).
  2. At least one policy per table for SELECT, INSERT, UPDATE, DELETE.
  3. No `USING (true)` policies — these are equivalent to no policy.
  4. Two-user isolation test: user A cannot read user B's data by URL manipulation.
  5. Service-role key is server-side only, not in any client bundle (grep the repo).
  6. No hard-coded secrets in the codebase (`process.env` only; `.env` in `.gitignore`).
  7. HTTPS enforced everywhere; no mixed content.
  8. Dependencies audited (`npm audit`, no high/critical vulnerabilities).

Section 2 — Authentication (6 checks)

  1. Sign-up works with email verification enforced.
  2. Sign-in works including password reset and expired-link recovery.
  3. OAuth redirects are environment-specific (no `localhost` in production).
  4. Session refresh works after expected expiry.
  5. Sign-out works cleanly; re-signing-in requires re-authentication.
  6. Rate limiting on auth endpoints (brute-force protection).

Section 3 — Payments (6 checks)

  1. Stripe secret key server-side only.
  2. Webhook signature verified on every request.
  3. Webhook idempotent (events table with unique constraint on `event.id`).
  4. Four core events handled: checkout.session.completed, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted.
  5. Card decline path tested with test card 4000 0000 0000 0002.
  6. Daily reconciliation cron runs and logs Stripe ↔ DB drift.

See our Stripe-in-Lovable checklist for the 14-point deep dive.

Section 4 — Email (4 checks)

  1. SPF, DKIM, DMARC authenticated for your sending domain.
  2. Welcome email hits Gmail inbox, not spam (test with a real address).
  3. Password reset email hits Outlook inbox, not spam.
  4. Bounce handling: invalid emails don't retry forever.

Section 5 — Deploy (6 checks)

  1. Env vars set correctly in both preview and production Vercel environments.
  2. Production deploy succeeds from a clean `main` branch push.
  3. Preview deploys work on every pull request.
  4. Rollback runbook written and tested once.
  5. Custom domain configured with correct DNS, SSL valid.
  6. Schema migrations tracked in git (Supabase CLI); staging project reflects production.

Section 6 — Performance (4 checks)

  1. Dashboard loads under 1 second with seeded production-scale data.
  2. Database indexes added for every frequent query (Supabase query-performance view).
  3. No N+1 queries on the main user flows.
  4. Images optimised: Next.js Image or equivalent, correct sizes.

Section 7 — Observability (6 checks)

  1. Error tracking installed (Sentry or equivalent) with alerts on production errors.
  2. Product analytics installed (PostHog or equivalent) with key events tracked.
  3. Logs accessible: Vercel logs + Supabase logs reachable within 2 minutes.
  4. Uptime monitoring on critical paths (homepage, sign-in, checkout).
  5. On-call contact documented; someone is reachable for incidents.
  6. Incident runbook: one-page checklist for the top 3 expected incidents.

Scoring your audit

FailuresWhat to do
0–2Fix the failures, launch confidently.
3–4Consider an Integration Fix for the specific failures, then launch.
5–10Book a Deploy-to-Production pass. Don't launch without it.
11+Full AI App Rescue or Platform Escape. Consider whether rescue or rewrite is the right frame.

What this checklist doesn't cover

The easiest path to passing

Run the checklist once yourself. If the number of failures is high or the technical checks are beyond your comfort zone, book the free 30-minute diagnostic. We'll walk through your specific failures, recommend a scope, and quote fixed fee inside 24 hours. Most pre-launch audits result in a Deploy-to-Production pass that closes the entire list in 3–4 weeks.

Related reading

FAQ
How long does the pre-launch audit take?
90 minutes for a non-technical founder working through the checklist methodically. A professional engineer runs the same audit in 45 minutes. Doing it once is the single highest-leverage pre-launch activity — every check here maps to a common post-launch incident.
Do I need technical help to run it?
Most checks are non-technical: clicking through the app, reading error messages, checking the Supabase dashboard. A handful (RLS policies, Stripe idempotency) require a developer or our Security Audit service. If a check reads as jargon, flag it for a developer instead of guessing.
What's the single most important check?
The two-user RLS test: sign in as user A, create data, sign in as user B, try to read user A's data. If it succeeds, your app has a disclosure vulnerability. This one check has caught more launch-blockers in our audits than any other.
What do I do if a check fails?
Don't launch. Fix it, or book a diagnostic. Fixing one check pre-launch is 5–10x cheaper than fixing it post-launch, once you've onboarded users and have an active incident window to manage.
Does the audit guarantee my app won't break?
No — it catches the 40 most-common failure modes. The long tail of edge cases requires load testing, user testing, and an incident response plan. But 90% of Lovable and Bolt launch-breakers are on this checklist.
Is there a more detailed audit service?
Yes — our Security Audit is a fixed-fee comprehensive pre-launch engagement that covers every check on this list, writes the missing RLS policies, and includes a written report. It's the level up when you've run the DIY audit and found problems.
When should I run the audit?
Once before first production deploy, once after adding any new integration (Stripe, OAuth provider), and once per quarter as a regression check. Running it quarterly catches the gradual drift that AI builders introduce over time.
Can I use this checklist for apps built without AI?
Yes. Every check reflects a general production invariant. AI-built apps fail them more frequently, but the checks are universal. Professional engineers run a variant of this checklist on every production launch.
Next step

Audit failing? Get a fixed-fee fix.

Free 30-minute diagnostic. Written scope and quote inside 24 hours.

Book free diagnostic →