Every MVP that took six months was a v1 wearing an MVP costume. The difference is rarely engineering speed - it's scoping discipline. Here is how we keep builds inside a 3-6 week window.
Define the one risky assumption
An MVP exists to answer one question: "will anyone use this to solve that problem?" Write that question down. Every feature that doesn't help answer it gets cut - auth providers, admin panels, settings pages, dark mode. All of it can wait.
Buy everything that isn't the answer
Payments? Stripe. Auth? A managed provider. Emails? A transactional service. Hosting? Boring and managed. Your differentiator is the workflow only you understand - spend 90% of the build there and assemble the rest from parts.
- Week 1: scope lock, architecture, walking skeleton deployed
- Weeks 2-4: the core loop, built end to end, demoed weekly
- Weeks 5-6: polish the single critical path, instrument analytics, launch to a real cohort
Ship to strangers, not friends
Friends are kind; strangers are honest. A landing page plus 20 real users beats 200 sign-ups from your network. Instrument the moment of value - the action that proves the product worked - and watch whether people reach it twice.
Plan the second version before the first ships
The MVP's job is to generate evidence. Decide in advance what result means "double down", "pivot", or "stop". Teams that skip this ship an MVP and then argue about what it meant.