How long does it take to build an MVP?
You've got an idea, you've started asking around, and now you have a spreadsheet's worth of conflicting answers. One agency says four to ten weeks. Another says three to four months is standard. A third quietly mentions six to twelve months once regulation or "enterprise-grade" comes up. You didn't ask which of those you'd be buying — you asked how long it takes, and nobody gave you a straight number.
That's not you failing to ask the question properly. It's that the question, asked on its own, doesn't have a number for an answer. Two people can describe the same idea and walk away with timelines three months apart, and both of them can be right, because they scoped different products and called them by the same name.
Here's the part that actually helps: once you see what the timeline is really measuring, you can predict roughly where your own idea will land before anyone quotes you anything.
The honest answer
An MVP's timeline is a function of one thing: how ruthlessly the scope was cut before anyone opened a code editor. Not the industry, not the platform, not even the complexity of the idea in the abstract — the number of things version one is trying to prove.
An idea with one core action, one type of user, and one way of judging whether it worked, is a matter of weeks. The same idea with three user types, a settings page, an admin dashboard nobody asked for yet, and "while we're at it" features bolted on before launch, is a matter of months — not because it's a better product, but because it's a longer list.
That's why our own answer for a properly scoped first version is four weeks. Not as a marketing number — as what's actually achievable once the list is cut to the one thing that needs proving. The agencies quoting three to four months as standard aren't wrong either; they're usually quoting a list that was never cut in the first place, then building a proper waterfall project around it and calling it an MVP because the client asked for one.
What actually stretches a timeline
It's rarely the difficult technical bit. The features people assume will take the longest — payments, logins, a slick interface — are mostly solved problems with well-worn tools. What actually adds weeks tends to be quieter than that.
Indecision costs more than complexity. A feature that's genuinely hard to build gets built once, correctly, because there's no ambiguity about what it needs to do. A feature nobody's agreed on gets built, reviewed, half-changed, and rebuilt, because "make it better" isn't a specification. The slowest weeks on any build are rarely the technically hardest ones — they're the ones spent waiting for someone to decide.
Every addition after the scope is set costs more than it looks like it should. Not because the feature itself is large, but because it reopens decisions that were already closed — a new field on a form means revisiting the database, the validation, the screen that displays it, and the test that checks it. A handful of small "while we're in there" additions, each individually reasonable, is how a four-week build quietly becomes a ten-week one without anyone deciding it should.
Waiting on someone else's system is invisible until it isn't. A payment provider's verification process, a third-party API's approval queue, an app store's review window — none of these are your developer's fault or yours, and none of them show up when someone quotes you a number of weeks for "the build." They still eat calendar time.
Regulation changes the category, not just the timeline. If the product handles health data, financial transactions, or anything else genuinely regulated, the honest comparison isn't "MVP" at all — it's a different kind of project with compliance work baked in from week one, and pretending otherwise just delays the moment you find out.
An idea that stays in planning is indistinguishable from no idea. The gap between "we're going to build something" and "real users are using something" is where most new ventures quietly die — and it's usually a scope problem, not a money problem. The smallest version that can prove the idea wrong is worth more than the grandest version that never ships. Every week spent adding things before launch is a week the idea spends unproven, which is a worse position than a smaller version already in front of real people.
A rough way to tell where you'll land
Before anyone quotes you a number, answer this yourself: if you had to cut your idea down to the one thing it needs to do to prove it works — one user type, one core action, nothing else — what would be left? Write that list. Then look at what you actually described to the last person who asked "so what does it do?" If the two lists match, you're close to a weeks-long build. If your answer to "so what does it do?" is noticeably longer than your cut-down list, that gap is where the extra months are hiding, and it's worth closing before you ask anyone for a quote at all.
Where that leaves you
There isn't a single honest number for "how long does an MVP take" — there's only a scope, cut or not cut, and a timeline that follows from it. If yours is genuinely cut to the one thing it needs to prove, four weeks is a realistic, not optimistic, answer. If it isn't yet, that's worth doing before the first conversation with anyone who'll be building it, because the cutting is the part that actually decides your timeline — the build itself mostly just executes the decision.
That's the whole premise behind our MVP development work: one idea, one build, four weeks, because the scope gets cut to the bone before anything's coded rather than discovered halfway through. If you're not sure yet whether your idea would survive that cut, tell us what it does in a sentence or two and we'll give you a straight answer on whether four weeks fits — and if it doesn't yet, what would need to go.
The same instinct — trusting a developer who defines "done" before they start, over one who doesn't — is worth applying to whoever you're about to hire, not just to your own scope. We've written about what separates a properly vetted build from a drifting one: the pattern is identical, whether it's your list that needs cutting or theirs that needs pinning down.
← All posts