How long does it really take to build an MVP

The short answer: six to twelve weeks, assuming the scope is defined and somebody is empowered to decide. That range assumes a narrow product with one user path, authentication, data persistence, failure states and measurement — not a demonstration that looks good and collapses when you click in the wrong place.

What decides where you land in the range?

Not typing speed. The three variables that actually decide are how many decisions were still open when development started, how quickly an answer arrives when a question comes up, and how many external systems are involved. A project where every question waits a week for an answer will land at the top of the range even with an excellent team.

• Open decisions at the start: each is eventually priced as though both options were implemented.
• The decision-maker's response time — the one variable a founder controls completely.
• External integrations: payments, identity, third-party systems. Each adds an approval cycle outside your control.
• Content and asset readiness: copy, logo, terms of use. These block launches more often than people expect.

Why do estimates collapse?

The common failure is not under-estimating development but ignoring everything that is not development. Design, testing, fixes, environment setup, app store review, a privacy policy — all of it is real time that never appears in a table where somebody is counting screens.

Timelines are also usually built on the scenario in which nothing surprises anyone. We plan with explicit slack for fixes after the first contact with users, because that contact always generates work, and generating that work is the entire reason for doing it.

What does a typical split of the time look like?

On a narrow first version the split we keep seeing runs roughly like this: about a third on definition and design, about half on development, and the rest on testing, fixes, environment setup and launch. The part that surprises founders is the first — they expect design to take a week, and it almost never does.

The last part surprises them less but gets cut more. When a schedule tightens, testing is what disappears first, and that is exactly what drags the project backwards two weeks after launch. Cutting a capability up front beats cutting the testing of that capability at the end.

Can it be shortened?

Yes, but not on every axis. You can narrow scope, you can drop support for secondary devices, and you can use existing services for authentication and payments instead of building them. What cannot really be shortened without cost is failure states and testing against a real user.

The most effective compression happens before development rather than during it: settle the open decisions. We set the method out in our piece on defining scope, and the comparison between kinds of development partner in software house vs freelancer.