MVP Checklist

What an MVP Actually Is

An MVP (Minimum Viable Product) is the smallest version of your product that lets you test your core assumption with real users. It is not a rough draft of your final product — it is a learning tool.

The MVP is done when: a real user can complete the core workflow, you can observe whether they got value, and you can collect payment (or at least a commitment) if they did.

It is NOT done when: you have added every feature you thought of, the design is polished, or you feel confident about every edge case. Ship before you feel ready.

Pre-Launch Checklist

Idea and Validation

• [ ] One-sentence problem statement written (the "[User] struggles to [X] because [Y]" format)
• [ ] At least 10 target-user conversations completed — problem confirmed to be real and painful
• [ ] At least 3 people have said they would pay for a solution
• [ ] Competitive landscape mapped — you know who else is solving this and why your approach differs
• [ ] Core assumption identified — the one thing that has to be true for this to work

Product Definition

• [ ] The MVP's single core workflow defined — one user story, end to end
• [ ] Scope cut aggressively — every "nice to have" removed until only the core remains
• [ ] Success metric defined — how will you know in 30 days if this is working?

Tech Foundation

• [ ] Repository created on GitHub with a clear README
• [ ] Environment variables documented (.env.example committed; actual .env in .gitignore)
• [ ] TypeScript configured from the start
• [ ] Linter and formatter configured (ESLint + Prettier)
• [ ] npm run build passes with no errors or type errors
• [ ] Local dev setup works reliably (npm run dev)

Authentication

• [ ] Sign-up flow works end to end (email/password or OAuth)
• [ ] Login/logout work correctly
• [ ] Session persists across browser refreshes
• [ ] Protected routes redirect unauthenticated users to login
• [ ] Email verification implemented (if applicable)
• [ ] Password reset flow works (if using email/password)

Core Feature

• [ ] The core workflow is complete and usable by a real person
• [ ] Happy path tested manually by someone who is not the developer
• [ ] Error states handled (what happens when something goes wrong?)
• [ ] Loading states shown (never let the UI look frozen)
• [ ] Empty states handled (what does a new user see before they have any data?)

Database

• [ ] Schema designed and documented
• [ ] Migrations applied to production database
• [ ] Basic input validation on all writes (never trust user input)
• [ ] No SQL injection vulnerabilities (use parameterized queries or an ORM)
• [ ] Backups configured on the database provider

Security

• [ ] HTTPS enforced everywhere (most hosts do this automatically)
• [ ] API keys and secrets in environment variables, never in code
• [ ] Auth checked on every protected API route — not just the frontend
• [ ] Rate limiting on auth endpoints (login, sign-up, password reset)
• [ ] User input sanitized before storing or displaying
• [ ] CORS configured correctly on the API (no wildcard * in production if avoidable)

Payments (if monetized at launch)

• [ ] Stripe account created and verified
• [ ] Test mode used during development (fake card: 4242 4242 4242 4242)
• [ ] Checkout flow works end to end in test mode
• [ ] Webhook endpoint set up and verified (not just the redirect URL)
• [ ] Subscription status stored in the database and checked when granting access
• [ ] Customer Portal linked for users to manage their subscription
• [ ] Stripe keys rotated from test to production before launch

Email

• [ ] Sending domain verified (SPF, DKIM, DMARC records added)
• [ ] Transactional emails working: welcome, password reset, receipt
• [ ] Emails render correctly in Gmail, Outlook, and mobile
• [ ] From address is a real domain you control (hello@yourdomain.com, not Gmail)

Deployment

• [ ] Production environment variables set (different from dev)
• [ ] Custom domain configured and SSL active
• [ ] Deployment is automated (push to main → auto-deploy)
• [ ] Production database is separate from development
• [ ] Previous builds do not serve stale assets after a new deploy

Monitoring

• [ ] Error tracking set up (Sentry free tier takes 30 minutes)
• [ ] Uptime monitoring configured (UptimeRobot — 5 minutes)
• [ ] You have a Slack or email alert for when the site goes down
• [ ] Basic analytics installed (PostHog or GA4)
• [ ] You know how to read your server logs

Legal Minimum

• [ ] Privacy Policy page published (you can generate one at Termly or iubenda)
• [ ] Terms of Service page published
• [ ] Cookie consent banner if serving EU users (required by GDPR)
• [ ] Unsubscribe link in marketing emails (required by CAN-SPAM)
• [ ] You understand your platform's content and liability exposure

Launch Checklist

Pre-Launch Day

• [ ] Full end-to-end flow tested in production (not dev) — sign up, use the core feature, pay
• [ ] Tested on mobile (Safari on iOS, Chrome on Android)
• [ ] Tested on a slow network (Chrome DevTools → Network → "Slow 3G")
• [ ] Favicon, OG image, and page title/description set
• [ ] 404 page exists and is styled
• [ ] No broken links or images

Going Live

• [ ] First 10 users identified (friends, interviewees, communities you belong to)
• [ ] Personal outreach plan written — not a tweet, not a Product Hunt post, direct messages to real people
• [ ] Where will you share it? (HackerNews "Show HN", relevant subreddits, Twitter, LinkedIn, a specific Slack or Discord community)
• [ ] You can process a real payment right now

Post-Launch: The First 30 Days

The launch is not the finish line. The first 30 days are about collecting signal.

Week 1

• [ ] Watch 5+ session recordings (PostHog) of real users using the product
• [ ] Talk to every new user — email them directly, ask what confused them
• [ ] Log every bug reported, no matter how small
• [ ] Fix the top 3 friction points you observed in session recordings

Week 2–4

• [ ] Identify your activation metric — what action separates users who "get it" from those who do not?
• [ ] Calculate your 7-day retention rate (% of sign-ups who return after 1 week)
• [ ] Identify the most common drop-off point in the sign-up / onboarding flow
• [ ] Ship one improvement per day or per week based on what you observed

Key Questions to Answer in 30 Days

• Did users complete the core workflow without help?
• Did any users return a second or third time?
• Did any users pay (or express willingness to pay)?
• What feature did every user ask for that you did not build?
• What did you build that no one used?

Common MVP Mistakes

• Building in secret for 3+ months — ship in 4–6 weeks max; users will find your product imperfect regardless of how long you waited
• Skipping the sign-up flow until later — auth is foundational; every day you wait is a day you cannot get real users in
• Paying for infrastructure before you need it — the free tiers of Vercel, Supabase, PostHog, and Sentry cover most MVPs
• Premature optimization — do not worry about database indexes, caching, or horizontal scaling until you have a measured problem
• Building features no one asked for — if it came from your imagination rather than a user conversation, cut it
• Treating "launched" as the goal — launch is the beginning of the work, not the end

Minimum Viable Infrastructure at Launch

Total fixed cost: $10–$15/year until you start earning meaningful revenue.

The goal of the MVP is not to build a perfect product. It is to find out, as cheaply and quickly as possible, whether the problem you are solving is one people will pay you to fix.