Eight weeks fit when you cut scope before writing code. A team that opens the editor in the first meeting burns those weeks on features nobody asked for, architecture outside the budget, and flows that miss the journey of whoever buys.
Marty Cagan argues in Inspired (Wiley, 2017) that the team validates the problem before it discusses the solution. Teams that start with the feature list spend the deadline building the answer to the wrong question.
Weeks 1 and 2: define before you write
The temptation is to open the editor at the first meeting. Hold off. The first two weeks produce four written answers:
- Central hypothesis: what you validate and the number that proves it
- Real user: the profile that installs the first version, drop "every potential customer"
- Minimum flow: the path from zero to the moment the product works, with everything else cut
- Critical dependencies: integrations, external APIs, and authentication that block the rest when they wait
Rob Fitzpatrick covers the first answer in The Mom Test (2013): you ask about the buyer's life instead of the idea. Those four answers become the written scope for the six weeks that follow.
Weeks 3 and 4: architecture that survives launch
Decisions in this phase set the cost of every sprint up to launch day:
- Use the stack the team knows. Eight weeks do not absorb the learning curve of a new framework.
- Stay on the monolith. A monolith cut by domain scales past where most MVPs get, and Martin Fowler makes the same case in "MonolithFirst" (2015).
- Turn on observability in week 1: logs, error tracking, usage metrics. Week 7 runs on that data.
- Automate the deploy on day 1: a simple pipeline removes manual errors and shortens lead time, the indicator Forsgren, Humble, and Kim tie to delivery speed in Accelerate (2018).
Weeks 5 and 6: the core flow
With the foundation in place, you ship the flow mapped in week 1 and nothing else. Every request outside it goes to a separate list, the post-launch validation backlog. "The customer will want this" states a hypothesis, and the hypothesis this MVP exists to test sits on page one of the scope document.
The separate list keeps the ideas and leaves the delivery alone.
Week 7: stabilize
You spend the week adding nothing: manual passes over the core flow, bug fixes, performance checks on a real network, a security review. The week exists so the list of known bugs is written before launch day.
Week 8: launch with instruments
Launch opens the learning phase, and learning needs data. You turn on product analytics, conversion tracking on the core flow, and a feedback channel with the first users. Eric Ries lays out the build-measure-learn loop in The Lean Startup (Crown Business, 2011).
Without those three instruments you publish and repeat the same bet.
What technical leadership does on an MVP
Most MVPs die from uncontrolled scope. Scope is a leadership problem. Someone has to turn down the week 5 feature that pushes launch, pick architecture that does not become a rewrite in November, and keep the team inside the mapped flow.
Senior technical leadership, in-house or through a short consulting engagement, keeps an eight-week MVP shipping a product the team can maintain after week eight.
