Every founder asks this and almost nobody asks the version of it that has a useful answer.
"How long should an MVP take" is a question about duration. The thing you actually need to know is what fits inside a duration — because those are the same question asked from opposite ends, and only one of them can be answered before the scoping conversation happens.
I've written separately about what has to be true for a four-week build to actually ship. This is the other half: how to think about the timeline you should be asking for in the first place, and how to read the answer you get.
The timeline is an output, not an input
Here is the mistake, and it is nearly universal.
A founder decides they need an MVP in six weeks, because the raise is in eight. They take that number to three suppliers and ask "can you do it in six weeks?" All three say yes. Of course they do — it's a yes-or-no question about a scope nobody has defined yet, and no is a losing answer.
What the founder has done is turn the timeline into an input. Once it's an input, it stops carrying information. The six weeks was true when it was a constraint on what to build, and it became meaningless the moment it was used as a test of who to hire.
The version that works runs the other way. You bring the deadline as a constraint, and the supplier's job is to tell you what fits inside it — specifically and in writing, with the things that don't fit named. The duration was never the negotiation. The scope is the negotiation, and the duration is what falls out of it.
Which means the most useful thing you can do with a quoted timeline is ignore it for a moment and look at how it was produced.
What the phases actually are
Any honest MVP timeline, whatever its length, decomposes into the same four things. Knowing the shape lets you sanity-check a quote without being technical.
Deciding what to build. Hours to a couple of days, and it is the highest-leverage time in the whole project. This is where features get cut. If a supplier wants to skip it and start building, the cutting will happen later, unilaterally, in week three, when they run out of time — and you will not be consulted.
The unfamiliar part. Every build has one thing nobody has done before: a model whose quality is unknown, an integration with badly documented software, a performance requirement that might not be achievable. This is where the schedule risk lives, all of it. A timeline that hasn't identified its unfamiliar part hasn't been thought about; it's been estimated by analogy with a different project.
The known part. Auth, storage, forms, deployment, the shape of the screens. This is genuinely faster than it was five years ago — this is where the tooling shift shows up, and where reusable scaffolding pays. It's also where an inexperienced estimate spends most of its contingency, which is exactly backwards.
Making it survivable. Error handling, the states nobody demos, logging, handover docs, the retraining script, the thing that stops it falling over when someone uses it wrong. This is what separates a product from a demo, it always takes longer than anyone budgets, and it is the first thing sacrificed when a build is running late. If a timeline has no visible allocation for it, the timeline is a demo timeline.
Ask a supplier to split their number across those four. Not because the split needs to be precise, but because someone who can do it has planned the work, and someone who can't has priced a vibe.
So what's the number?
For a pre-seed MVP that answers one clear question, built by one senior engineer with modern tooling and real scope discipline: four weeks is the number I commit to, and I think it's the honest one for that shape of work.
Some builds land sooner. A consumer AI build last spring had a working MVP in the founder's hands at the end of week one, and spent the remaining three weeks getting to a beta that real people could use. I still quote four, because a commitment you sometimes beat is worth more than an average you sometimes miss, and because the week-one build was a small scope well cut, not a general capability.
Some builds shouldn't be four weeks. If the smallest useful version of your product is still six months — hard regulatory surface, safety-critical behaviour, a genuinely novel research problem — then no amount of tooling compresses it, and anyone telling you otherwise is selling you the first month of a six-month project with the other five removed.
The two failure modes at the edges are worth naming. Under two weeks, you are almost certainly buying a prototype: something that demonstrates rather than works. That's a legitimate purchase, but don't confuse it with a product, and don't take it to users. Beyond about three months without an intermediate shipped thing, you have stopped doing pre-seed MVP work and started building a product on faith, with no feedback until the money is spent.
What a good timeline conversation sounds like
It sounds like disagreement, early, about scope. It sounds like someone saying "not in four weeks, but here's what is" and then telling you what they'd remove. It ends with a written scope and a date, agreed before anyone starts, and neither one moves without the other moving too.
What it doesn't sound like is enthusiasm. The most dangerous supplier conversation is the one where everything you ask for is possible, the timeline is whatever you need, and nobody argues with you. That conversation feels excellent and predicts a slip, because the argument you didn't have in week zero is the argument you're going to have in week three, when it costs both of you the deadline.
If you have a build and a date and you want to find out what actually fits between them, that's what the scoping call is for. Thirty minutes, no pitch, and if the answer is that four weeks doesn't fit your build, you'll get told that on the call rather than in week three.