Skip to content
SlashClone
DiscoverUse in ClaudeSubmit a link
Sign in
Made by@shipcheck

Launch checklist

@shipcheck/launch-checklist

A pre-launch check for your first real app. Reads your project, detects the stack (Supabase, Stripe, Next.js, auth, email), and writes a checklist split into blockers, first-week items, and later, with evidence from your code for each item it could verify. Covers data access, payments, secrets, auth, abuse limits, errors and monitoring, backups, email deliverability, legal pages, and SEO basics.

SkillDevOpsv1.0.0 (latest)
Use in Claude Save Like Clone Comment
Activity
New: be the first to try it
  1. 1---
  2. 2name: launch-checklist
  3. 3description: Pre-launch review for a first real app, especially one built with a coding agent. Reads the project, detects the stack (Supabase, Firebase, Stripe, Next.js, Vite, Clerk or Supabase Auth, Resend), checks what it can in code, and writes docs/launch-checklist.md split into Blockers, First week, and Later, each item marked verified, failing, or ask. Use when the user says "I'm about to launch", "what am I missing before going live", "is this ready for real users", "launch checklist", or before turning on Stripe live mode or posting on Product Hunt.
  4. 4license: MIT
  5. 5---
  6. 6
  7. 7# Launch checklist
  8. 8
  9. 9Turns "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.
  10. 10
  11. 11## Steps
  12. 12
  13. 131. **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.
  14. 142. **Ask three questions** (skip any the code answers):
  15. 15 - Who are the first users: friends, a waitlist, or the public?
  16. 16 - Does it take money on day one?
  17. 17 - Does it store anything personal beyond email (health, finance, kids, location)?
  18. 183. **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.
  19. 194. **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.
  20. 205. **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.
  21. 21
  22. 22## The checklist
  23. 23
  24. 24**Blockers (fix before real users):**
  25. 25- Data access: every table readable from the browser has row level security or an equivalent rule; users cannot read each other's rows.
  26. 26- Secrets: no `.env` in git; no server keys behind `NEXT_PUBLIC_` or `VITE_`; no keys in code.
  27. 27- 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.
  28. 28- 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.
  29. 29- Server routes: every API route that changes data checks who is calling.
  30. 30- Production env vars are set on the host for Production, not only Preview.
  31. 31
  32. 32**First week:**
  33. 33- Errors: an error tracker or at least host logs you know how to read; a friendly 404 and error page.
  34. 34- 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.
  35. 35- Email: sending domain has SPF, DKIM, and DMARC; transactional email comes from your domain.
  36. 36- Backups: the database plan includes backups and the user knows how to restore one.
  37. 37- Uptime: a free uptime monitor on the home page and the main API route.
  38. 38- Legal: privacy policy and terms pages if collecting emails or money; cookie banner only if using non-essential cookies in regions that need it.
  39. 39
  40. 40**Later:**
  41. 41- SEO basics: title and description per page, Open Graph image, sitemap, robots file.
  42. 42- Analytics on the one or two events that matter (sign-up, first key action, payment).
  43. 43- Account deletion and data export.
  44. 44- Staging environment or preview deploys tested before production.
  45. 45
  46. 46## Output format
  47. 47
  48. 48```markdown
  49. 49# Launch checklist: <app>, <date>
  50. 50Stack: Next.js 15, Supabase, Stripe, Vercel
  51. 51
  52. 52## Blockers (2 failing, 4 verified, 1 ask)
  53. 53- [ ] FAILING Payments: success page grants access (app/success/page.tsx:12). Grant in the webhook instead.
  54. 54- [x] VERIFIED Secrets: .env* ignored (.gitignore:3), no public-prefixed server keys.
  55. 55- [ ] ASK Production env vars: are STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET set for Production on Vercel?
  56. 56
  57. 57## First week
  58. 58## Later
  59. 59```
  60. 60
  61. 61## Guardrails
  62. 62
  63. 63- Evidence or it is an `ask`. Never mark an item verified without pointing at the file that shows it.
  64. 64- Never open or print `.env` files; check `.gitignore` and variable names instead.
  65. 65- Never change hosting, DNS, payment, or database settings. Write what to change and where.
  66. 66- Keep it short. A 60-item list nobody finishes is worse than 12 items that get done.
Sign in to comment on a line