What a four-week MVP actually contains
A short timeline is a scoping discipline, not a speed claim. Here is what makes the cut and what deliberately does not.
When we say a first build takes four to six weeks, the reaction is usually either scepticism or relief, and both are slightly misplaced. The timeline isn't a claim about typing speed. It's a claim about what a first version should contain.
The constraint is the point
Given twelve weeks, a team will fill twelve weeks. Scope expands to match the runway available to it, and most of the expansion goes into work that cannot be validated because there are no users yet to validate it against.
A short first cycle forces a question onto every proposed feature: does this need to exist before anyone has used the product? For most features the honest answer is no.
What goes in
- One primary flow, finished properly. The single path that delivers the product's core value, built to a standard you would defend in front of a paying user.
- Authentication and accounts. Unavoidable, and cheap when done early.
- The data model. The part that is genuinely expensive to change later, so it gets disproportionate attention up front.
- Instrumentation. If the first version teaches you nothing, the speed was wasted.
- A real deployment. On its own domain, with monitoring, from week one.
What stays out
- Admin panels that a database client already covers
- Settings for preferences no user has expressed
- Second and third user roles, before the first one is proven
- Optimisation for a scale that does not yet exist
- Anything justified by the phrase "while we're in there"
The trade you're making
You are trading completeness for information. At the end of the cycle you have a narrower product than a twelve-week build would produce, and considerably better evidence about which direction the next twelve weeks should go.
That trade is a good one for almost every new product, and a poor one for a system replacing something already load-bearing. Knowing which situation you're in is most of the decision.
After launch
The first two weeks post-launch usually reshuffle the roadmap more than the preceding month of planning did. Users do things nobody anticipated, ignore features that seemed essential, and ask repeatedly for something that was never on the list.
Build the first version fast enough that you can afford to listen.