Launch checklist

Launch checklist

Turns "am I ready to launch?" into a short, ranked list built from the user's actual code. Each item is either verified (with the file that proves it), failing (with the file that shows it), or a question only the user can answer. Generic advice the project does not need is left out.

Steps

1. Detect the stack. Read package.json, the framework config, and the folder layout. Note: framework, database (Supabase, Firebase, Prisma), auth, payments, email, hosting (vercel.json, netlify.toml), analytics, error tracking. Tell the user what you found in one line and ask them to correct it.

2. Ask three questions (skip any the code answers):

   • Who are the first users: friends, a waitlist, or the public?
   • Does it take money on day one?
   • Does it store anything personal beyond email (health, finance, kids, location)?
3. Walk the checklist below. For each item, look for evidence in the code. Mark it verified (cite the file), failing (cite the file and line), or ask (only the user or a dashboard can tell). Skip items that do not apply, such as payments for a free app.
4. Point to deeper checks. If Supabase is used, suggest the supabase-rls-audit kit. If Stripe webhooks exist, suggest stripe-webhook-hardening. For secrets, suggest env-secrets-check. Run them if they are installed and the user agrees.
5. Write docs/launch-checklist.md in the format below. Blockers first, at most about 10 lines per section. Show it and offer to fix the failing blockers one at a time, each with its own yes.

The checklist

Blockers (fix before real users):

• Data access: every table readable from the browser has row level security or an equivalent rule; users cannot read each other's rows.
• Secrets: no .env in git; no server keys behind NEXT_PUBLIC_ or VITE_; no keys in code.
• Payments: webhook verifies signatures, uses the raw body, is idempotent; access is granted by the webhook, not the success page; prices come from the server, not the client.
• Auth: protected pages check the session on the server, not only by hiding links; password reset works; email confirmation is on if sign-up is public.
• Server routes: every API route that changes data checks who is calling.
• Production env vars are set on the host for Production, not only Preview.

First week:

• Errors: an error tracker or at least host logs you know how to read; a friendly 404 and error page.
• Abuse: rate limits on sign-up, login, contact forms, and any route that calls a paid API (AI, email, SMS); a spending cap set in each paid API's dashboard.
• Email: sending domain has SPF, DKIM, and DMARC; transactional email comes from your domain.
• Backups: the database plan includes backups and the user knows how to restore one.
• Uptime: a free uptime monitor on the home page and the main API route.
• Legal: privacy policy and terms pages if collecting emails or money; cookie banner only if using non-essential cookies in regions that need it.

Later:

• SEO basics: title and description per page, Open Graph image, sitemap, robots file.
• Analytics on the one or two events that matter (sign-up, first key action, payment).
• Account deletion and data export.
• Staging environment or preview deploys tested before production.

Output format

# Launch checklist: <app>, <date>
Stack: Next.js 15, Supabase, Stripe, Vercel

## Blockers (2 failing, 4 verified, 1 ask)
- [ ] FAILING Payments: success page grants access (app/success/page.tsx:12). Grant in the webhook instead.
- [x] VERIFIED Secrets: .env* ignored (.gitignore:3), no public-prefixed server keys.
- [ ] ASK Production env vars: are STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET set for Production on Vercel?

## First week
## Later

Guardrails

• Evidence or it is an ask. Never mark an item verified without pointing at the file that shows it.
• Never open or print .env files; check .gitignore and variable names instead.
• Never change hosting, DNS, payment, or database settings. Write what to change and where.
• Keep it short. A 60-item list nobody finishes is worse than 12 items that get done.

Launch checklist

A pre-launch review built from your actual code, not a generic list. It finds what your app uses, checks what it can, and writes a short checklist: blockers to fix before real users, things for the first week, and things for later.

For: anyone about to put their first real app in front of users or turn on payments, especially if a coding agent wrote much of it.

Example

Input: "I'm launching on Friday, what am I missing?" in a Next.js app with Supabase and Stripe.

Output (docs/launch-checklist.md):

# Launch checklist: my-app
Stack: Next.js 15, Supabase, Stripe, Vercel

## Blockers (2 failing, 4 verified, 1 ask)
- [ ] FAILING Payments: success page grants access (app/success/page.tsx:12).
      Grant access in the webhook instead.
- [ ] FAILING Data access: table "invoices" has no row level security
      (supabase/migrations/0001_init.sql:30).
- [x] VERIFIED Secrets: .env* ignored (.gitignore:3).
- [ ] ASK Are your Stripe keys set for Production on Vercel?

## First week
- [ ] Rate limit /api/generate (calls a paid AI API, no limit found).
- [ ] SPF, DKIM, DMARC for your sending domain.

Every item is marked verified (with the file that proves it), failing (with the line), or ask.

What it can access

• Reads your project files. It does not open .env files.
• Writes one file: docs/launch-checklist.md.
• No scripts, network, or env vars. Works with Claude Code, Codex, and Cursor.

Pairs well with supabase-rls-audit, stripe-webhook-hardening, and env-secrets-check from Ship Check.

Setup

None.