How long does an MVP take? Real data points

In short: how long an MVP takes depends far more on how well the scope is written than on how fast developers type. A narrow, well-defined tool can have a first version in days; a product that changes the shape of the business (multi-tenant, integrated with legacy systems) takes months. I will not give you one universal range. Below are real data points from my own projects, what drives the difference, and how to estimate yours.

Real data points

What was built	What I can measure	What it shows
A specification for a new product	Ten working days: scoping interview, draft, review, final document and estimate	Writing the scope is a short, bounded job.
An independent risk audit of a codebase	Ten working days, access to readout	A fixed scope and date is possible.
An AI meeting summariser, first version	Nine commits in four days	A narrow, well-framed tool can ship a first version fast.
A B2B lead-sourcing and audit engine	About four weeks and 29 commits for the sourcing and audit layer; the automatic outreach layer deliberately held back until manual validation produced results	Staging the product avoids building what is not yet proven.
Turning a single-client tool into a multi-tenant SaaS	A six-phase, sixty-task plan, all completed	Changing the shape of the product is a project of its own.
Migrating three years of household budget history	61 categories, 731 budget cells and more, with no balance drift	Data migration is real work, not a footnote.

These are not promises for your project. They show the order of magnitude of different kinds of work, and that duration follows the kind of work, not the label "MVP".

What drives the duration

1. Scope clarity. Unwritten scope turns into change requests. See the PRD template.
2. Number of roles and interfaces. Each role is its own set of screens and rules. A product with an admin back-office, a customer view and a mobile app is several products.
3. Tenancy. Multi-tenant from day one costs more than single-tenant, and retrofitting it costs the most. See multi-tenant architecture explained.
4. Integrations and legacy systems. They hide the work that nobody saw in the brief.
5. Data migration. Cleaning and checking existing records takes real time.
6. Decision speed. A question that waits a week stalls the work behind it.
7. Testing and acceptance. Budget for business-side testing against written criteria.

How to estimate yours

1. Write the ranked requirements and the out-of-scope list.
2. Count the roles, interfaces and integrations.
3. Mark what is "later" and remove it from version one.
4. Ask two vendors to estimate the same document and list their assumptions (see comparing quotes).
5. Add time for decisions, data migration and acceptance, which vendors often leave out.

Cutting an MVP down

The best way to shorten an MVP is to remove requirements, not to ask developers to hurry. Ask of each feature: would a first customer refuse to use the product without it? If not, move it to "later". Ranking requirements into must-have, should-have and later is the discipline that makes a short first version possible.

Signs your timeline is slipping

Reporting turning vague, decisions taking more than a week, scope growing with no re-costing. See the five warning signs.

Get a grounded estimate

The Technical Specification & PRD offer ends with a build and budget estimate, a range with its assumptions attached, so you can tell whether a vendor's quote is aggressive, padded or quoting a different product. I write the document and do not bid on the build.