An MVP answers one question, not several
The most common way a six-week build fails is not running out of time. It is arriving at week six with something that works and still not knowing whether the idea does. That happens when the build was scoped around features rather than around a question.
So week one produces one sentence, and everything else follows from it. Not a marketplace for X but will suppliers list inventory without us calling them? Not an AI writing tool but will people paste their own document in, rather than start from a template?
A good question has a wrong answer you would believe. If no result would change your plans, you are building for reassurance, and six weeks is an expensive way to get it.
What you cut, in order
Once the question is fixed, the cuts stop being painful and start being obvious. In rough order of what goes first:
- Settings and preferences. Almost always a way of avoiding a decision. Pick the default.
- Admin interfaces. A spreadsheet and a person is a legitimate v1 back office.
- Onboarding beyond the first screen. If the product needs a tour to be usable, that is a finding, not a feature gap.
- Every account state you do not need to test. Password reset can be an email to you.
- The second user type. Two-sided products still test one side first.
What never gets cut: the actual moment of value, the state where things go wrong, and instrumentation that answers the question. Analytics is not optional in an MVP. It is the deliverable.
How the six weeks are actually spent
It is not a straight line from design to build. Design runs ahead by about a week and never stops:
- Week 1 the question, the flow, what we are not building. Written down and agreed.
- Week 2 core screens designed; backend and infrastructure started in parallel.
- Weeks 3 to 4 the build. Design stays a week ahead and handles what the build uncovers, because it always uncovers something.
- Week 5 real data, real edge cases, deploy to your infrastructure. This week is uglier than it looks on a plan.
- Week 6 instrumentation, handover, and the walkthrough.
When six weeks is the wrong answer
We turn this down more often than we run it. It is the wrong shape when the product needs a regulatory review before launch, when the core value depends on integrations you do not control yet, or when there is genuinely no question left: when you have paying users and a roadmap, and what you actually need is a team, not a sprint.
It is also wrong when the founder cannot be available. Six weeks with a decision-maker who answers in a day works. Six weeks with a weekly review cycle is a ten-week project with a worse ending.