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.
| Category | Items | The one thing you cannot skip |
|---|---|---|
| Product | 1–6 | Core flow ships end-to-end with no manual ops in the middle |
| Engineering | 7–14 | CI on every PR, forward-only migrations, a tested backup restore |
| Security & compliance | 15–22 | Managed auth, HTTPS + HSTS, a working GDPR/CCPA deletion flow |
| Billing & payments | 23–28 | Stripe live with idempotent webhooks and lawful cancellation |
| Observability & reliability | 29–34 | Error tracking, external uptime checks, alerts that reach a human |
| Analytics & growth | 35–39 | 5–10 named events and a funnel to paid you can read in 60 seconds |
| Legal | 40–42 | Lawyer-reviewed privacy policy, ToS and blocking cookie consent |
| Marketing & launch | 43–45 | Landing page passes Core Web Vitals; launch comms actually drafted |
| Post-launch ops | 46–47 | Staffed 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)
- One sentence positioning is written and tested. Required. The 8-word version a customer will repeat to a peer. Tested against 5 target users.
- The core flow ships end-to-end without help. Required. Signup → activation → value moment → payment, with no manual ops in the middle.
- 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.
- Error states are designed and human. Strong default. “Something went wrong” is a failure of product, not an error message.
- Onboarding completes in under 4 minutes. Strong default. Measured, not assumed. Time-to-value is the single most important MVP metric.
- 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)
- All environments use IaC. Strong default. Terraform, Pulumi or SST. Click-ops infra is a launch blocker by month three.
- CI pipeline runs on every PR. Required. Lint, typecheck, unit tests, build. Below 10 minutes end-to-end.
- Database migrations are forward-only and idempotent. Required. Sqitch, Flyway, Prisma Migrate or Drizzle Kit. No “run this SQL by hand on prod.”
- Secrets are in a vault, not in env files. Required. AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Rotated.
- Backups are tested. Required. Not just configured — restored at least once from production data to a fresh DB.
- Rate limiting on auth and payment endpoints. Required. 100 req/min per IP at minimum; harder limits on signup, login, password reset.
- Mobile builds signed with proper distribution certificates. Required if mobile. Lost certificate = lost ability to ship updates.
- 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)
- HTTPS everywhere with HSTS. Required. No mixed content. HSTS preload submitted.
- Content Security Policy is set and tested. Strong default. Even a lax CSP catches whole classes of XSS.
- Auth uses a managed provider. Required. Clerk, Auth0, Supabase Auth, WorkOS, FusionAuth — not hand-rolled.
- Passwords are hashed with bcrypt/Argon2id. Required if you self-manage auth. Plaintext or MD5 in 2026 is unforgivable.
- RLS enforces tenant isolation (multi-tenant SaaS). Required. See multi-tenant SaaS architecture.
- Dependency scanning runs in CI. Strong default. Dependabot, Renovate, Snyk. Critical CVEs block merge.
- An incident runbook exists. Required. Who is on call, how to declare an incident, how to communicate with customers, how to post-mortem.
- 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)
- Stripe in production mode, webhooks verified. Required. Test mode = no revenue.
- Webhook handler is idempotent. Required. Stripe retries; without idempotency you bill twice.
- Failed payments trigger dunning. Required. Smart Retries on, dunning emails configured.
- Cancellation flow respects the law. Required. EU law and US FTC click-to-cancel rules require parity with the signup flow.
- VAT/sales tax handled. Required for EU sales. Stripe Tax or Quaderno covers most cases.
- Refund flow has a documented runbook. Strong default. Even MVPs get refund requests in week one.
Observability & reliability (29–34)
- Error tracking with stack traces. Required. Sentry, Rollbar, Bugsnag. Linked to releases for source-mapped traces.
- Structured logging. Required. JSON logs, request ID propagated end-to-end, tenant ID on every log line for multi-tenant.
- Basic metrics dashboard. Strong default. Latency, error rate, throughput. Datadog free tier, Grafana Cloud free tier, or self-hosted Prometheus.
- Uptime checks from outside your infra. Required. Better Uptime, Healthchecks.io, Pingdom. Two regions minimum.
- 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.
- 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)
- Product analytics instrumented with 5–10 named events. Required. PostHog or Amplitude. Activation, retention, conversion, engagement, plus product-specific value events.
- 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.
- UTM tagging is consistent across channels. Strong default. Otherwise attribution is fiction.
- Marketing site has Schema.org markup and a sitemap. Strong default. See technical SEO & growth.
- A feedback loop exists in product. Strong default. Linear feedback widget, Canny, or a simple email. Use it from day one.
Legal (40–42)
- Privacy policy + cookie consent + DPA template. Required. Lawyer-reviewed for any EU traffic. Don’t copy from another site.
- Terms of service. Required. Limit of liability, governing law, acceptable use, refund policy.
- 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)
- Landing page passes Core Web Vitals. Strong default. LCP < 2.5s, CLS < 0.1, INP < 200ms on mobile. PageSpeed score 90+.
- Open Graph and Twitter Cards configured. Strong default. Test with the actual cards debuggers, not just dev tools.
- 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)
- Support intake is staffed. Required. A real human responds within 4 hours during business days, 24 hours otherwise. Email + in-app at minimum.
- 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.
Common MVP Launch Mistakes to Avoid
The 47-item checklist above tells you what to do. These are the six things teams consistently get wrong — even when they have a checklist in front of them.
Building for everyone
Attempting to serve multiple personas in v1 produces a product that does nothing well. Pick one ICP, one use case, one core flow — and make that one thing undeniable before you expand. Every "this would also be useful for…" conversation during scoping is a scope-creep warning sign.
Over-engineering the tech stack
Kubernetes, event sourcing and a federated GraphQL layer are correct answers for a product with 200,000 users. For 200 users, they are sprint-killers. Choose the most proven stack your team already knows. You will have time to re-platform once the scale problem is real — and the scale problem is a good problem to have.
Skipping observability until “after launch”
Sentry, structured logs and an external uptime check take roughly one engineering day to instrument. Without them you will discover broken flows from an angry customer support ticket, not from a Slack alert at 2 am. The cost of instrumentation is fixed; the cost of a blind incident is not.
Delaying the billing integration
“We’ll add payments in the next sprint” is the most expensive sentence in early-stage SaaS. Billing touches auth, subscription state, feature gating and dunning. Retrofitting it adds two to three weeks and delays your first real revenue signal. Wire Stripe before launch, not after.
Launching without a feedback channel
Post-launch silence is not validation. If no one is telling you what to fix, it likely means no one is engaged enough to bother — and that is the signal you most need. Install an in-app feedback widget and schedule five 20-minute calls with early users in the first two weeks.
Treating red checklist items as acceptable risk without writing them down
Every required item left red is a known, accepted risk. The discipline is to document it explicitly: what is the risk, who owns it, what is the mitigation date. A red item with no record is not a decision — it is a blind spot waiting to become an incident.
Rule of thumb: if you are hesitating on a required item, that hesitation is the answer. Required items earned their status because a real incident burned someone who skipped them.
Post-Launch: Collecting and Acting on User Feedback
Shipping is the starting line, not the finish. The highest-value work in an MVP’s first 30 days is not adding new features — it is finding out whether the features you shipped actually solve the problem you thought you were solving.
Set up a lightweight feedback intake on day one
Install a feedback widget (Canny, Linear, or a mailto: link styled as a button) before you launch. Personal emails from the founder to the first 20–50 users convert far better than automated sequences. Keep them short: “What’s working? What’s confusing? What would make you upgrade?”
Run weekly 20-minute calls for the first four weeks
Five calls per week, 20 minutes each — that is 100 minutes of unfiltered signal. Users will not proactively report the thing that confused them; they will work around it and say nothing. A call surfaces this in ways a survey never will. Bring a list of three questions, then stop talking.
Build-Measure-Learn cadence
Deploy a small hypothesis, observe the outcome in your analytics and support queue, interview three to five users, prioritise one change, ship it in the next two-week sprint. Teams that run this cycle well find product-market fit in four to six iterations; teams that skip it tend to run out of runway re-polishing features nobody uses.
| Post-launch week | Focus metric | Desired output |
|---|---|---|
| 1–2 | Activation — does the user reach the value moment? | Activation rate %, drop-off step identified |
| 3–4 | Retention — do they return next day and next week? | D1/D7 retention, top-3 churn reasons |
| 5–8 | Conversion — free-to-paid rate and upgrade triggers | Conversion rate %, pricing signal, upgrade friction |
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.
What tech stack should I use for my MVP?
Use the most proven stack your team already knows: Next.js/React + Node.js or Python for web MVPs; React Native or Flutter for cross-platform mobile. Avoid microservices, event sourcing and federated GraphQL until you have a real scale problem — they slow a small team by 30–50%. You can re-platform when scale is real; right now speed is the only constraint that matters.
How long does it take to build an MVP?
A focused, scope-controlled MVP ships in 8–16 weeks with a 3–5 person team. The most common causes of overrun: scope added after kickoff, under-staffed engineering (one developer for a 50-screen product), and billing or auth retrofitted after the fact rather than wired in from day one.
How big a team do I need to build an MVP?
Minimum viable team: one product owner, two engineers, one part-time designer. That combination ships a production-grade MVP in 10–14 weeks. One engineer alone takes 6–9 months and produces something architecturally fragile. Five engineers without a dedicated PM produces a well-built product that solves the wrong problem.
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 15 September 2026.
