A 12-week MVP roadmap covering problem validation, scope cut, design, build, beta and launch, for founders shipping the first version of a software product.
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
01
Problem validation
Weeks 1–2
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
02
Scope cut
Week 3
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
03
Design
Weeks 3–5
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
04
Build
Weeks 4–10
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
05
Beta
Weeks 9–11
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
06
Launch
Week 12
Public launch: Product Hunt, Hacker News, LinkedIn, customer email. Pricing live. Onboarding tested. Support email monitored. Plan for a week of chaos, because 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
01Cut scope twice. The first cut is too generous; the second one is closer to honest.
02Pre-sell before building if you can. The strongest validation signal is money.
03Demo to a real user every Friday. The fast feedback prevents building things nobody wants.
04Resist mid-build feature additions. Every "small" feature delays launch by 1–2 weeks.
05Plan 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.
Gantt Chart Maker