Elena Marchetti, YuSMP Group
Elena Marchetti Head of Product, YuSMP Group · 12+ years shipping B2B SaaS for US and EU teams

What should be on an MVP launch checklist?

Short answer: a production-grade MVP launch checklist runs to about 47 items across nine categories: product, engineering, security, billing, observability, analytics, legal, marketing and post-launch ops. Security, billing and observability are the parts you never bargain on. Feature polish is where you cut hard. And if a single required item comes up red, you don’t launch — that’s the whole point of running the list.

The table below lays out the nine categories and, for each one, the single item you cannot skip. It’s the same audit our engineers run before they sign off an MVP build. Read it in one screen to get your bearings, then work through all 47 items in full underneath.

CategoryItemsThe one thing you cannot skip
Product1–6Core flow ships end-to-end with no manual ops in the middle
Engineering7–14CI on every PR, forward-only migrations, a tested backup restore
Security & compliance15–22Managed auth, HTTPS + HSTS, a working GDPR/CCPA deletion flow
Billing & payments23–28Stripe live with idempotent webhooks and lawful cancellation
Observability & reliability29–34Error tracking, external uptime checks, alerts that reach a human
Analytics & growth35–395–10 named events and a funnel to paid you can read in 60 seconds
Legal40–42Lawyer-reviewed privacy policy, ToS and blocking cookie consent
Marketing & launch43–45Landing page passes Core Web Vitals; launch comms actually drafted
Post-launch ops46–47Staffed support and pre-allocated week-one fix capacity

How to use the checklist

Each item carries one of three weights. Required means you don’t launch without it. Strong default means you skip it only with a written reason. Nice-to-have can wait until after launch. Against every item, note two things: who owns it (PM, engineer, founder, lawyer) and the evidence that it’s done (a URL, a screenshot, a link to a passing test). A checkbox with nothing behind it isn’t done.

Run the whole thing in one sitting, team in the room, in 2–4 hours. If it drags past that, the delay is usually the answer: something isn’t clear yet, and you’re not ready to ship.

Product (1–6)

  1. One sentence positioning is written and tested. Required. The 8-word version a customer will repeat to a peer. Tested against 5 target users.
  2. The core flow ships end-to-end without help. Required. Signup → activation → value moment → payment, with no manual ops in the middle.
  3. Empty states are designed. Strong default. Give every list, dashboard and feed a real empty state that tells the user what to do next, rather than a blank screen.
  4. Error states are designed and human. Strong default. “Something went wrong” is a failure of product, not an error message.
  5. Onboarding completes in under 4 minutes. Strong default. Measured, not assumed. Time-to-value is the single most important MVP metric.
  6. Pricing page reflects the actual billing implementation. Required. If the page says “cancel anytime” and the cancel flow takes 4 emails, you have a fraud claim waiting.

Engineering (7–14)

  1. All environments use IaC. Strong default. Terraform, Pulumi or SST. Click-ops infra is a launch blocker by month three.
  2. CI pipeline runs on every PR. Required. Lint, typecheck, unit tests, build. Below 10 minutes end-to-end.
  3. Database migrations are forward-only and idempotent. Required. Sqitch, Flyway, Prisma Migrate or Drizzle Kit. No “run this SQL by hand on prod.”
  4. Secrets are in a vault, not in env files. Required. AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Rotated.
  5. Backups are tested. Required. Not just configured — restored at least once from production data to a fresh DB.
  6. Rate limiting on auth and payment endpoints. Required. 100 req/min per IP at minimum; harder limits on signup, login, password reset.
  7. Mobile builds signed with proper distribution certificates. Required if mobile. Lost certificate = lost ability to ship updates.
  8. A staging environment exists and is used. Strong default. Same shape as prod, fed from anonymised data. PR previews are nice; staging is mandatory.

Security & compliance (15–22)

  1. HTTPS everywhere with HSTS. Required. No mixed content. HSTS preload submitted.
  2. Content Security Policy is set and tested. Strong default. Even a lax CSP catches whole classes of XSS.
  3. Auth uses a managed provider. Required. Clerk, Auth0, Supabase Auth, WorkOS, FusionAuth — not hand-rolled.
  4. Passwords are hashed with bcrypt/Argon2id. Required if you self-manage auth. Plaintext or MD5 in 2026 is unforgivable.
  5. RLS enforces tenant isolation (multi-tenant SaaS). Required. See multi-tenant SaaS architecture.
  6. Dependency scanning runs in CI. Strong default. Dependabot, Renovate, Snyk. Critical CVEs block merge.
  7. An incident runbook exists. Required. Who is on call, how to declare an incident, how to communicate with customers, how to post-mortem.
  8. GDPR/CCPA data-deletion flow works. Required if you have EU or California users. End-to-end test covers user-initiated deletion across DB, blob, analytics and logs.

Billing & payments (23–28)

  1. Stripe in production mode, webhooks verified. Required. Test mode = no revenue.
  2. Webhook handler is idempotent. Required. Stripe retries; without idempotency you bill twice.
  3. Failed payments trigger dunning. Required. Smart Retries on, dunning emails configured.
  4. Cancellation flow respects the law. Required. EU law and US FTC click-to-cancel rules require parity with the signup flow.
  5. VAT/sales tax handled. Required for EU sales. Stripe Tax or Quaderno covers most cases.
  6. Refund flow has a documented runbook. Strong default. Even MVPs get refund requests in week one.

Observability & reliability (29–34)

  1. Error tracking with stack traces. Required. Sentry, Rollbar, Bugsnag. Linked to releases for source-mapped traces.
  2. Structured logging. Required. JSON logs, request ID propagated end-to-end, tenant ID on every log line for multi-tenant.
  3. Basic metrics dashboard. Strong default. Latency, error rate, throughput. Datadog free tier, Grafana Cloud free tier, or self-hosted Prometheus.
  4. Uptime checks from outside your infra. Required. Better Uptime, Healthchecks.io, Pingdom. Two regions minimum.
  5. Alerts go to a human, not just a Slack channel. Required. PagerDuty, OpsGenie, or a phone number will do. A muted channel notices nothing at 3am; a person you can page does.
  6. Status page exists. Strong default. statuspage.io, Instatus, BetterStack Status. Customers will trust you more for admitting downtime than for hiding it.

Analytics & growth (35–39)

  1. Product analytics instrumented with 5–10 named events. Required. PostHog or Amplitude. Activation, retention, conversion, engagement, plus product-specific value events.
  2. Funnel from landing page to paid is measurable. Required. You should be able to answer “how many of last week’s visitors paid?” in 60 seconds.
  3. UTM tagging is consistent across channels. Strong default. Otherwise attribution is fiction.
  4. Marketing site has Schema.org markup and a sitemap. Strong default. See technical SEO & growth.
  5. A feedback loop exists in product. Strong default. Linear feedback widget, Canny, or a simple email. Use it from day one.
  1. Privacy policy + cookie consent + DPA template. Required. Lawyer-reviewed for any EU traffic. Don’t copy from another site.
  2. Terms of service. Required. Limit of liability, governing law, acceptable use, refund policy.
  3. Cookie consent banner properly blocks non-essential cookies until consent. Required for EU. Klaro, Cookiebot, Iubenda. “Accept all” only is no longer compliant.

Marketing & launch (43–45)

  1. Landing page passes Core Web Vitals. Strong default. LCP < 2.5s, CLS < 0.1, INP < 200ms on mobile. PageSpeed score 90+.
  2. Open Graph and Twitter Cards configured. Strong default. Test with the actual cards debuggers, not just dev tools.
  3. Launch comms drafted. Strong default. Email to waitlist, social posts, Product Hunt draft, founder LinkedIn post. Drafted, not just intended.

Post-launch ops (46–47)

  1. Support intake is staffed. Required. A real human responds within 4 hours during business days, 24 hours otherwise. Email + in-app at minimum.
  2. The roadmap has a “week one”, “month one” and “quarter one” bucket. Required. Pre-allocated capacity for the inevitable bugs and small fixes. Without it, the team burns out by week three.
Startup founder working through an MVP checklist
47 items. 2–4 hours with the team in one room. If any required item is red, you don’t launch.

FAQ

How many items should an MVP launch checklist have?

Our production list is 47 across nine categories. Fewer than ~30 misses critical work; more than ~70 is over-scoped.

What is the most commonly skipped item before MVP launch?

Production observability. Founders launch with no error tracking and discover in week two that 14% of users hit an error path silently.

Do I need a privacy policy for my MVP?

Yes. Even small EU/US user bases trigger GDPR/CCPA obligations. Not optional.

Should the MVP have an admin panel?

Yes — a simple one. Retool, Forest Admin or a 1-day in-app admin. Saves 5–10 support hours per week.

How much testing does an MVP need?

Unit tests on payment, auth and tenant-isolation. Playwright smoke tests on 3–5 critical flows. Skip exhaustive E2E.

What metrics should I instrument before launch?

Activation, retention (D1/D7/D30), conversion (free to paid), engagement, and one product-specific value metric. Free PostHog or Amplitude tier covers it.

Get a launch audit before you ship

One day of senior engineering. You get a red/amber/green tick-list, the riskiest fixes ranked in order, and a written go/no-go opinion you can act on. Teams tend to book it just before a launch, ahead of a raise, or when the first enterprise pilot is about to sign.

Last updated 3 July 2026.