# How Long Should It Take to Build an MVP? The Honest Answer

> Source: [https://botensten.com/articles/how-long-to-build-an-mvp](https://botensten.com/articles/how-long-to-build-an-mvp) (canonical)
> Author: Botensten — Botensten, https://botensten.com
> Published: 2026-08-21

## TL;DR

A minimum viable product should take two to eight weeks to build, not months. A landing-page or concierge test can take one to seven days; a narrow single-workflow app usually lands in four to six weeks. If your first version needs a full quarter of engineering, you have scoped a product, not a test. The MVP exists to answer one risky question fast: will a specific person pay for or repeatedly use a specific outcome. Cut everything that does not answer it.

## How long should it take to build an MVP?

Most MVPs should take two to eight weeks to build, not months. If your first version needs a full quarter of engineering, you have scoped a product, not a test. An MVP exists to answer one risky question: will a specific person pay for, or repeatedly use, a specific outcome? Anything that does not help answer that question gets cut. Speed is the whole point.

The honest range is two to eight weeks for one core workflow. A landing page or concierge test can take a single day. A narrow, working software MVP usually lands in four to six weeks. Past eight weeks, you are almost always building features nobody has asked for yet.

## What actually counts as a "minimum" viable product?

An MVP is the smallest thing that produces a real signal from real users. It is not a shrunken version of your dream app; it is a test with a scorecard. Eric Ries defined it in [The Lean Startup](http://theleanstartup.com/) as the version that collects the maximum validated learning with the least effort.

Minimum means one workflow, one user type, one outcome. Everything else — settings pages, onboarding tours, admin dashboards, five integrations — is deferred. If a feature does not change what you learn this month, it does not belong in the MVP. Write down the single sentence your MVP must prove, then delete anything on the roadmap that does not test it.

## Why do longer MVP timelines usually signal a problem?

A long timeline almost always means the scope is wrong, not that the work is hard. When an MVP creeps past two months, the cause is usually unvalidated assumptions dressed up as requirements. CB Insights' analysis of startup post-mortems found 35% of failed startups cited "no market need" as a top reason ([CB Insights, Top Reasons Startups Fail](https://www.cbinsights.com/research/startup-failure-reasons-top/)). That is exactly what happens when you build for a quarter before talking to buyers.

The fix is talking to customers before and during the build. Rob Fitzpatrick's [The Mom Test](https://www.momtestbook.com/) shows how to get truthful answers by asking about past behavior, not future intentions. Ten honest conversations will cut your build scope faster than any planning meeting.

## How we scope an MVP to ship in weeks

We build production software with AI every day, and our rule is blunt: nothing ships in the first version unless it moves the core bet. A recent internal tool went from idea to usable in a weekend because we cut everything except the one screen the user actually needed. Two days of building, one day watching people use it.

The trade-offs were real and deliberate. We skipped auth roles, used SQLite instead of a managed database, and hard-coded the two states we needed instead of a config system. That cost us cleanup later, and we knew it going in. It was worth it because we learned in three days whether anyone would use the thing. Here is the loop we run:

1. Write the one sentence the MVP must prove.
2. Talk to five to ten target users this week.
3. Cut every feature that does not test that sentence.
4. Build the single workflow end to end, with real data.
5. Put it in front of five users and watch them use it.

We reuse an existing stack on purpose — Bun, Elysia, and SQLite on a small server we already run. New tools feel productive but quietly burn your timeline. AI writes most of the boilerplate now, which means the bottleneck is no longer typing code; it is deciding what not to build.

## Which MVP type fits your timeline?

Pick the lightest MVP that still produces a real buying or usage signal. The heavier the format, the longer it takes and the more you should have already validated. Use this table to match ambition to time.

| MVP type | Typical time | Best for | Signal you get |
|---|---|---|---|
| Landing page + waitlist | 1-2 days | Demand for a promise | Sign-ups, click-through |
| Concierge (manual delivery) | 3-7 days | Testing the outcome | Willingness to pay |
| Single-workflow app | 2-6 weeks | One core job | Real usage, retention |
| Multi-feature product | 8+ weeks | Already-proven demand | Depends on prior tests |

Start at the top and only move down once the lighter test passes. Most founders skip straight to the bottom row and pay for it in wasted months.

## When is it okay to spend longer than eight weeks?

Spend longer only when the market need is already proven and the risk is technical, not demand. If you have paying users waiting and the hard part is genuinely the engineering — a real-time system, a regulated workflow, a hardware dependency — a longer build is honest. Ash Maurya's Running Lean calls this de-risking the right constraint first.

Watch for these signs your longer timeline is justified:

- Users are already paying or sitting on a real waitlist.
- The core risk is "can we build it," not "does anyone want it."
- You have shipped a lighter MVP that already passed.
- The complexity is essential to the outcome, not to your comfort.

If none of those are true, the timeline is a symptom. Cut scope, ship the single workflow in weeks, and let real users tell you what to build next.

## Related reading

- [How Do You Validate a Business Idea? The Honest Playbook](/articles/how-to-validate-a-business-idea-2)
- [What Does Building an MVP Actually Mean?](/articles/what-does-building-an-mvp-mean)
- [Why Is It Important to Build an MVP?](/articles/why-build-an-mvp)
- [How Do I Start a Business? A Build-In-Public Playbook](/articles/how-to-start-a-business-startup-bootstrapping-playbook)

## Frequently asked questions

**How long should it take to build an MVP?**

Two to eight weeks for a working single-workflow app, and one to seven days for a landing-page or concierge test. If it takes a full quarter, the scope is too big for a minimum test.

**What is the fastest kind of MVP?**

A landing page with a waitlist, which can be built in one to two days. It measures demand for a promise before you write any product code.

**Why does my MVP keep taking longer than planned?**

Usually because unvalidated assumptions are being treated as requirements. Talk to five to ten target users and cut every feature that does not test your core sentence.

**Should I build an MVP before talking to customers?**

No. Have ten honest conversations first, focused on past behavior rather than future intentions, so you build only the one workflow that matters.

**Can AI make MVPs faster to build?**

Yes. AI writes most boilerplate, so the bottleneck shifts from typing code to deciding what not to build. The scoping discipline matters more than the coding speed.

**When is a longer MVP timeline actually justified?**

Only when demand is already proven and the remaining risk is technical, such as a real-time, regulated, or hardware-dependent system with paying users waiting.

**How do I know my MVP is small enough?**

It should cover one workflow, one user type, and one outcome. If you can not describe it in a single sentence, it is still too big.