We have shipped MVPs in as little as six weeks. We have also watched projects with eight-week timelines stretch to eight months. The difference is almost never technical. It is almost always about decisions — who makes them, how fast, and how clearly the scope was defined before a single line of code was written.
Week 1 is not for building
The fastest projects we have delivered all had one thing in common: a well-defined Week 1 that was entirely about alignment, not code. User flows mapped. Database schema drafted. API contracts agreed. Design system chosen. Tech stack decided. Deployment pipeline set up. If you skip this week and start building immediately, you will rebuild everything twice.
What MVP actually means
Minimum Viable Product does not mean the smallest thing you can get away with. It means the smallest thing that proves the core hypothesis. If you are building a marketplace, the hypothesis might be "users will pay to access this supply." The MVP tests that and nothing else. Every feature that does not test the hypothesis is scope creep, regardless of how reasonable it sounds.
The three-meeting rule
Every week, we run three meetings: a Monday kickoff (what are we building this sprint), a midweek checkpoint (are we on track or do we need to cut scope), and a Friday demo (show working software, not designs). The Friday demo is the most important. If you are showing designs in week five, you are not building an MVP — you are planning one.
Where projects die: scope creep after kick-off
"Can we just add one more thing?" is the most expensive sentence in software development. Scope creep on a fixed-timeline project does not add features — it removes quality. Every addition is a subtraction from something else. The right answer to mid-project feature requests is: yes, in version 2. Write it down, prioritise it for after launch, and keep building what you agreed to build.
What you actually get at week eight
A working product that handles the core user journey end-to-end. Basic auth, core workflow, data persistence, working on mobile and desktop. Not a polished product — a shippable one. The polish comes after you have real users telling you what they actually need, not what they thought they needed in the kick-off meeting.