How to actually ship an MVP in 12 weeks
Most MVPs fail because they're scoped like products and built like prototypes. Here's the playbook we use to ship real products in a quarter.
The 12-week MVP isn't a marketing slogan
It's a constraint that forces good decisions. Most MVPs miss the deadline because they confuse shipping fast with scoping fast. We've built enough of these to know the difference.
Week 0: Pick the wedge, not the platform
An MVP that tries to be a platform is a 9-month project wearing an MVP costume. Pick the single workflow that demonstrates your value, and put a paywall in front of it.
Weeks 1–2: Cut, then cut again
Every "while we're at it" is a week. Every "we'll need this for v2" is a month. Anything that doesn't directly cause first revenue is moved to a parking lot doc you can ignore.
Weeks 3–8: Build like adults
An MVP is not an excuse for bad code. The codebase your first engineering hire inherits should be clean, typed, and observable. Otherwise you'll rebuild it in month 4.
Weeks 9–10: Onboard your first 10 customers
If onboarding requires a Loom and a calendar invite, that's fine — but you should be sitting next to those first customers learning what breaks.
Weeks 11–12: Charge real money
An MVP without payment is a prototype. The single most informative event in your company's life is the first time someone hands you a credit card. Don't postpone it.
What we keep cutting
- Settings pages no one will visit before month 6
- Workflows that don't change conversion
- Custom design systems before a design language exists
- Microservices before there's a monolith worth splitting
What we always keep
- Auth, billing, and analytics — wired from day one
- Observability you'd want at 10x the traffic
- A clean enough codebase that hire #1 doesn't quit
Twelve weeks is enough. It's not a lot, but it's enough — if you spend it on the things that matter.