How long does it take to build an MVP?

Cost is the first question founders ask and timeline is the second, usually because something depends on it: a raise, a conference, a customer who has been promised something, or runway that does not care how good the product is.

The short answer for a focused first version is three to six weeks. The longer answer is that the estimate is the least interesting part, because most overruns are not caused by the engineering being slower than expected.

Realistic timelines by product type

These assume the scope is settled before the build starts and that someone is available to answer questions within a day. Both assumptions are load-bearing, and both are usually where the time actually goes.

The five things that move the date

Four of these are on your side of the table, which is the genuinely useful thing to know before you commission anything.

1. How settled the scope is. A scope that changes in week three does not cost you week three — it costs whatever was built on top of the assumption that changed.
2. How fast decisions get made. If a question takes four days to answer, the build has a four-day hole in it. The single cheapest thing you can do for your own timeline is be reachable.
3. Third parties. Payment providers, KYC vendors, insurers and banks move at their own speed. Sandbox access and production approval are frequently the longest pole, and they start the day you apply, not the day you need them.
4. Whether design exists. Building from an agreed design is fast. Designing while building means rework, and rework is invisible in the original estimate.
5. The engineering itself. Last on the list on purpose. It is the most predictable part and rarely the reason a date slips.

Why fixed dates work better than estimates

An estimate invites negotiation about scope during the build. A fixed date inverts it: the date holds, and scope is what flexes. That is uncomfortable the first time and it is the arrangement that ships.

It only works if somebody is willing to cut. If nothing can be removed, the date was never real — it was a hope with a number attached. What belongs in an MVP is the cutting exercise done properly.

This is also why we quote fixed scope and fixed price rather than day rates. Time and materials makes overrun the client's problem, and an overrun on an MVP is usually a scoping failure rather than an engineering one.

Three to four weeks: what that actually means

We say three to four weeks for an MVP, and it is worth being precise about what is inside that window, because the claim is meaningless otherwise:

• Week one: scope agreed and written down, production foundations up, first working software on a live URL.
• Weeks two to three: the core built in the order that lets you see it weekly and redirect in days rather than at the end.
• Week four: deployment, monitoring, the unglamorous parts — auth, payments, admin — and handover.

What is not inside it: discovery, which happens before and is quoted separately; regulated compliance work; and anything blocked on a third party who has not approved you yet.

What makes a timeline slip after launch

Real users find things. Reserve time for the sprint immediately after launch — it is the most valuable development time in the whole project, because for the first time you are building against evidence instead of assumption.

Teams that skip it start the second version on guesses again, which is how a product ends up needing re-architecture much earlier than it should. Why MVPs break at scale covers what that looks like.

What we do

We build MVPs to a fixed scope and a fixed date, with working software on a live URL every week so the date is visible rather than promised. If your timeline is driven by something external — a raise, a conference, a customer — say so on the first call, because it changes what we recommend cutting.

If the honest answer is that what you want cannot be built well in the time you have, you will hear that on the call rather than in week five.

Frequently asked questions