How long does an MVP really take to build?

Ask three agencies how long your MVP will take and you’ll get three confident answers, all measured in months, none explaining what drives the number. The honest answer is that an MVP takes as long as its scope demands, and scope is a decision, not a fact of nature. Founders who treat it that way ship in weeks. Founders who don’t, ship in quarters, if at all. And the clock underneath is not the schedule; it is runway. A slipped quarter is not a delay, it is a smaller company by the time you launch.

What actually drives the timeline

Four things, roughly in order of impact:

• Scope.The number of screens, flows, and roles is the timeline. Every “while we’re at it” feature is paid for in weeks.
• Decision speed.A build stalls every time it waits on an unanswered question. Founders who turn decisions around in a day keep a build moving; committees don’t.
• Integrations.Payments, identity, and third-party APIs are where estimates go to die, because the other side of the integration doesn’t care about your launch date.
• Novelty.Boring, proven foundations are fast. Genuinely novel technology is research, and research doesn’t estimate well. Most MVPs need far less novelty than their founders think.

What “weeks not quarters” actually requires

Shipping an MVP in weeks isn’t heroics. It is a small senior team, a scope that has been argued down to what actually tests the idea, and progress you can see and redirect every two weeks instead of a reveal at the end. It also requires someone with the standing to say “don’t build that yet” and make it stick. Most money wasted on software isn’t bad code; it’s building the wrong thing.

The version-one test

For every feature on the list, ask: does the idea fail without this? If users can’t tell you whether the product works without the feature, it stays. Otherwise it waits for version two, when real usage will tell you whether it was ever needed. Admin panels, settings pages, and edge-case flows are the usual suspects: needed eventually, fatal to a timeline now.

The discipline doesn’t end at version one. In 2025 I sat down with a B2B SaaS CEO whose delivery team was shipping genuinely impressive work: technically complex features, well built, each one defensible on its own. Her frustration was the chart underneath. “All these things we believe will lift acquisition or conversion,” she told me, “aren’t.” So we ran a workshop and put all fifty items on the roadmap through the same wringer: what result do we believe this produces, for how many customers, with how much confidence, at what cost? Product people will recognise the shape of RICE scoring in that; the framework matters less than the honesty it forces. Thirty of the fifty items didn’t survive, somewhere between three and six months of engineering time. Not because the features were bad, but because nobody had ever made each one answer what it was for.

The most memorable casualty was the shiniest thing on the list: an AI feature that demoed beautifully and could not say what outcome it produced. Nobody had wanted to be the one to cut it. It went anyway. The rule underneath is one we hold our own work to: AI featureshave to clear the same bar as every other line on the roadmap. We build them for a living, and we’ll still tell you when one is a toy.

And the cost question

Cost follows the same drivers as time, which is why a fixed number quoted before anyone has argued about scope should worry you. The useful sequence is scope first, then price: agree what version one actually is, in writing, in plain English, and the number attached to it becomes something you can hold someone to. That is how we run product development engagements: a short proposal, a scope somebody is willing to fight for, and working software every two weeks so you never wonder where the money went.

If you only ask one question

If a build plan is measured in quarters, the question to ask isn’t “can you go faster?” It’s “what is in this scope that my idea doesn’t need in order to be tested?” The answer is usually the difference between weeks and quarters.