Article
Founders ask this question first, and most answers are either evasive or a number with no reasoning behind it. Here is ours, with the reasoning. A minimum viable product, built by senior engineers who have done it before, takes six to ten weeks from the first conversation to real users. When it takes longer, it is almost always because the "minimum" was never decided.
What the weeks are for
One week of scope. Three to five days of architecture. Three to five weeks of build. One week of hardening. A few days to launch. That is the shape of our MVP Sprint, and the shape has been stable across very different products because the phases are about the process, not the domain.
The build is the shortest part people expect and the longest part people plan for. It is three to five weeks because the scope phase made it that size.
The decision that sets the timeline
In the first week, the feature list is split in two: what is built now and what is built later. Everything a customer needs to get value on day one goes in the first list. Everything else, including things that feel essential, goes in the second. The build-now list is what makes the product viable; the build-later list is what makes the timeline honest.
This is uncomfortable. A founder has usually been thinking about the product for a year and every feature has a reason. But a product with twenty features takes twenty features' worth of time, and the ones that matter cannot be learned about until the product is in front of users. Cutting is not a compromise; it is the mechanism by which the MVP does its job, which is to find out what the product should be.
What makes it six weeks rather than ten
A clear owner who can decide within a day. Integrations that are spiked in the first week so their surprises appear early. A staging environment from the second week, so feedback shapes the build instead of arriving after it. And a team that has built this kind of thing before, so architecture is a few days of decisions rather than a few weeks of research.
What makes it six months
Scope that grows without anything being removed. Design that is still being decided while the build is underway. A dependency on a third party that has not agreed to anything. And, most often, the absence of a written scope, so nobody can say what "done" means and the build continues until the money runs out.
What you get at the end
A working product in front of real users. Tests on the paths that matter. Monitoring. Documentation. Every repository and account in your name. And a build-later list that is now a roadmap informed by real usage, which is worth more than the list you started with.
If the honest answer is "not an MVP"
Sometimes the build-now list, after cutting, is still four months of work. That is not an MVP; it is a platform, and it should be planned as one, with milestones and a dedicated team. We say so in the scope phase, and the SaaS Platform Build is the shape that takes. The worst outcome is a six-month project sold as a six-week one, and the scope phase exists to prevent it.