How long a real MVP should take, and why six weeks is common

Founders often ask for a specific number before scoping has even started, and six to eight weeks tends to be the honest answer for a well-scoped MVP built around one core workflow. That's not an arbitrary industry figure; it's a function of a few specific phases that don't compress much further without cutting something important along the way.

Cutting the idea down to one testable workflow, and designing the actual screens for it, takes real time even for a narrow scope. Compressing this phase tends to produce a build that starts before the team actually agrees on what's being built, which costs more time later than it saves upfront, usually in the form of rework mid-build.

This is where scope discipline earns its keep. A single complete workflow, built on a mature stack with managed infrastructure for the boring parts, authentication, storage, is a three to four week build for an experienced team. Scope creep during this phase is the single biggest driver of MVPs that take three or four months instead of six weeks.

Before calling an MVP done, we want it in front of a small number of real users, not just internally tested. This surfaces the obvious bugs and confusing moments that internal testing misses, and it's the phase most likely to get skipped when a team is eager to call the project finished before it's genuinely ready.

A founder who's already done real customer discovery, and arrives with a clearly validated single assumption rather than a vague idea, can shave real time off the scoping phase. The build and testing phases compress less, since those are mostly a function of the work itself rather than how prepared the founder is going in.

One MVP took eleven weeks instead of the typical six to eight, because mid-build the founder's initial customer conversations revealed the original workflow was testing the wrong assumption entirely. We rescoped rather than push forward on a build that would have answered the wrong question. Slower and correct beat fast and irrelevant in that case.

Founders who arrive having already run real customer conversations, ideally with notes, not just memory, can move through scoping meaningfully faster than founders starting from a purely internal idea with no outside validation yet. We ask for this upfront specifically because it changes what's realistically achievable in the timeline.

Six to eight weeks assumes a dedicated team working the project as a genuine priority. The same amount of actual work stretched across a team splitting attention across several concurrent projects can take meaningfully longer in calendar time, even though the total hours of effort involved doesn't change.

A faster timeline is possible by cutting scope further, not by working the same scope faster, since the actual limiting factor is usually decisions and design clarity, not raw coding speed. We're direct about this tradeoff whenever a founder pushes for an aggressive four-week timeline.

When an external deadline is earlier than a properly scoped MVP timeline allows, we're honest about the tradeoff rather than silently agreeing to an unrealistic date. Usually that means further narrowing scope specifically to hit the fixed date, cutting to whatever can genuinely be built well in the available time, rather than compressing the same scope into less time.

Building both a web and mobile MVP at once roughly doubles the realistic timeline rather than running the same six to eight weeks in parallel, since design, backend, and testing work don't fully overlap between the two. We usually recommend sequencing them, validating on one platform before committing to the second, unless there's a specific reason both are needed from day one.

A founder who's slow to respond to design and product questions during the build, because they're still working a full-time job elsewhere, for instance, can meaningfully extend even a well-scoped six to eight week timeline, since our team ends up waiting on decisions only the founder can make. We flag this explicitly during scoping and ask directly how much dedicated time the founder can realistically commit during the build window.

We also set a specific, named decision point at the end of the pilot phase, a date by which the founder commits to either moving forward, pivoting the workflow being tested, or stopping altogether, rather than letting the pilot phase quietly drift on indefinitely without a clear resolution. Founders who skip defining this decision point in advance sometimes find themselves running an informal, extended pilot for months without ever quite deciding whether the original assumption was actually validated, which defeats much of the point of having scoped a fast, focused MVP in the first place.

A founder who's already been through this process once with a previous product tends to move through the scoping phase noticeably faster, since they arrive already understanding the discipline of narrowing scope and don't need to be talked out of an overbuilt initial vision the way a genuinely first-time founder often does. We still run the full process, but the actual calendar time spent on scoping conversations is often meaningfully shorter for a repeat founder.

A founder occasionally realizes partway through a six-week build that a second workflow feels essential too, not just the original single one being tested. We push back firmly here, since adding real scope mid-build is exactly the pattern that turns a six-week MVP into a four-month one. If the second workflow genuinely can't wait, we treat it as a distinct second phase with its own separate timeline, rather than quietly folding it into the current build and letting the original deadline slip without anyone explicitly deciding that was acceptable.

This firm line has occasionally frustrated a founder eager to move faster, but it's protected far more MVP timelines than it's disappointed founders, and the ones who've been through it once tend to specifically ask us to hold that same line on their next project.