How long does it take to build an MVP? A realistic timeline

A focused MVP takes 4-6 weeks. What fits in that time, a week-by-week shape, what makes it take longer, and what you must never cut to get there faster.

The honest timeline for a minimum viable product is shorter than most people fear and longer than most demos suggest. It is short because a real MVP does one thing. It takes longer than a demo because that one thing has to work for real users, on real data, without a rewrite waiting behind it.

The short answer: a focused MVP takes 4-6 weeks. That covers one kind of user, one core job done properly, and the foundations (data model, login and permissions, and a deploy pipeline) that version two can build on. More user types, integrations, payments or data migration push it longer.

What fits in 4-6 weeks

A well-scoped MVP includes:

  • One user and one job. The single thing the product has to do well, from signup to the moment the user gets what they came for.
  • The core flow, finished properly. Everything around it stays deliberately thin, but the main path is complete.
  • The data model, identity and permissions. The three things a rewrite is usually made of, done right the first time.
  • A deploy pipeline from week one. A staging environment and repeatable releases before the first feature, so shipping is routine rather than an event.
  • Measurement on the paths that matter. So the first release answers a question instead of starting an argument.

A week-by-week shape

Every project differs, but a focused MVP usually follows this rhythm:

  1. Week 1: discovery and scope. Who the user is, what job they need done, and a written cut list of everything that is not in version one.
  2. Week 2: design and foundations. The core flow designed and clickable, the data model and permissions settled, and the deploy pipeline running.
  3. Weeks 3-5: build. Working software deployed every week to an environment you can open, not a status report describing one.
  4. Week 6: launch and measure. Real users, real data, and the first numbers on whether the idea works.

What makes it take longer

These are the usual reasons an MVP grows past six weeks:

  • More than one kind of user. Customers plus staff plus admins means more flows and more permissions.
  • Integrations. Payments, accounting or an external API each add work, more if the API is poorly documented.
  • Existing data to migrate. Bringing records across from an old system or spreadsheets.
  • Native mobile apps. A web app that works well on phones is faster to ship than separate iOS and Android apps.
  • Scope that keeps moving. The biggest delay is not technical. It is adding "one more thing" every week.

What to cut, and what never to cut

Deciding what to cut is the easy part. The damage shows up later, in the decisions that are expensive to reverse.

Cut freely: extra features, settings screens, secondary integrations, admin polish, and anything a manual step can cover for the first few months.

Never cut: the data model, identity and permissions, and the deploy path. A login system that cannot hold a second type of user, a database that assumed one currency, or a deployment nobody can repeat turns version two into a rewrite.

Write the cut list down, with the reason for each item. It becomes the roadmap for version two, and it stops the same debates happening twice.

After launch

Launch is a measurement point, not a finish line. The weeks after release show which assumptions were right, which feature nobody uses, and what users ask for that nobody predicted. That evidence is what version two should be built on.

We ship our own products this way

GetFade and Nilo Learn are both live, both still ours to maintain, and both doing more now than their first release did, because the foundations were built for a second version from the start.

Frequently asked questions

Can an MVP be built in two weeks?

A prototype or a demo, yes. A product real users can rely on, rarely. The foundations that stop version two being a rewrite take time, and skipping them is the most expensive shortcut in software.

Will we have to rebuild the MVP later?

Not the foundations, if they were built properly. Feature code gets replaced as you learn, which is normal. A rewrite usually means the data model or the permission system was wrong.

What if our idea does not work?

Then you find out in weeks rather than after a year of building, which is the point of an MVP. And if discovery suggests the idea does not need custom software at all, we will say so.

Should the MVP be a mobile app?

Usually not at first. A fast web app that works well on phones reaches users sooner and costs less to change. Native apps make sense once you know what people actually use.

How much does an MVP cost?

The timeline drives the cost, so a 4-6 week MVP costs a fraction of a full platform. See how much custom software costs for what moves the number.

Where we come in

AN2Tech builds MVPs that are scoped to prove the idea and built so version two is an extension, not a rewrite. Email info@an2tech.com with the one thing your product has to do well.

More write-ups

How to add AI to your business software: a practical guide

Where AI pays off in a business, how to stop it giving wrong answers, what it costs to run, and a step-by-step way to add it to the software you already use.

Building AI agents: the hard part is not the model

AI agents are easy to demo and hard to put in front of customers. What we are building, and the four things that decide whether an agent survives real work.

Site Boost Engine: a growth service we ran on ourselves first

A proprietary growth engine, proven on our own products before we offered it to anyone. Results-driven, with reporting that shows the impact on your metrics.