About this template
Most MVPs ship 3–6 months late because the initial scope was too ambitious. The fix is not better project management — it is brutal scope cutting up front. This 12-week template assumes the problem is already validated with 5–10 potential customers and the team is genuinely ready to build. If the problem is not validated yet, do not skip phase 1 — that is the phase that prevents the wrong MVP.
How a 12-week MVP roadmap breaks down
Problem validation
Interview 10–20 people in your target ICP. Find the 3–5 strongest pain points. The strongest signal is people offering to pay before the product exists. Document the problem space in one page. If interviews do not produce a clear single pain point, do not start building — keep talking to people.
- Identify 20–30 interview targets
- Conduct 10–20 interviews
- Synthesize top pain points
- Single-page problem statement
- Validate by pre-selling if possible
Scope cut
List every feature anyone has ever suggested. Cut to 5–8. Cut again to 3–5. The MVP is what solves the core pain point and nothing else. Anything labeled "would be nice" is a future feature, not an MVP feature.
- Brainstorm full feature list
- Cut to 5–8 must-haves
- Cut again to 3–5 core MVP features
- Define success criteria
- Identify the one metric that matters
Design
Wireframes for every screen in the MVP. High-fidelity designs for primary flows only. Skip the design system if you can — pick a UI library and ship. Get 5 people to click through the prototype. The fast feedback prevents building things nobody wants.
- Wireframes (every screen)
- High-fidelity for primary flows
- Pick UI library (skip custom system)
- Click-through prototype
- 5-user feedback loop
Build
Build the 3–5 features. Hosting, auth, database, basic admin. Resist the urge to add features mid-build — every addition delays launch by 1–2 weeks. Stand-up daily so blockers surface fast. Demo to a friendly user every Friday.
- Hosting and auth setup
- Database schema
- Feature 1
- Feature 2
- Feature 3
- Basic admin
- Friday user demos
Beta
Onboard 5–20 beta users from the original interview list. Daily contact. Track what they actually use vs. what they say they want. The gap is your real insight. Fix the top 3 blockers each week. Capture testimonials from anyone who has a "wow" moment.
- Onboard 5–20 beta users
- Daily check-ins
- Track actual usage
- Fix top 3 blockers per week
- Capture testimonials
Launch
Public launch — Product Hunt, Hacker News, LinkedIn, customer email. Pricing live. Onboarding tested. Support email monitored. Plan for a week of chaos — every MVP launch surfaces issues that beta did not.
- Product Hunt launch
- Hacker News (Show HN)
- LinkedIn announce
- Customer email
- Pricing live
- Support monitoring
Tips from MVPs that shipped on time
- Cut scope twice. The first cut is too generous; the second one is closer to honest.
- Pre-sell before building if you can. The strongest validation signal is money.
- Demo to a real user every Friday. The fast feedback prevents building things nobody wants.
- Resist mid-build feature additions. Every "small" feature delays launch by 1–2 weeks.
- Plan for chaos in the launch week. Every MVP surfaces issues that beta did not.
Frequently asked questions
How long should an MVP take?
8–16 weeks. Anything longer than 4 months is rarely an MVP — it is a full product disguised as one.
How do I know the problem is validated?
When 10+ people in your ICP describe the same pain in their own words AND a meaningful fraction offer to pay before the product exists.
Should I bring on a co-founder before MVP?
Most successful founders say yes — solo MVPs that succeed are rare. But the co-founder fit matters more than the timeline.