How long a SaaS MVP takes: the method, not a number

How long a SaaS MVP takes is decided by its scope, and the scope is something you choose. A minimum viable product is the smallest version of a product that real customers can use and learn from; the honest answer to "how long?" is "as long as the scope you allow it", which is why the useful work is fixing the time first and cutting the scope to fit.

You'll find plenty of published averages. I don't quote them, because they mix products of very different sizes, and an average of a landing page and a marketplace tells you nothing about yours. What I can give you is the method, and the time-boxes that established product methods publish, which are a better guide than any average.

What is an MVP for?

The Lean Startup frames the minimum viable product as the way "to begin the process of learning as quickly as possible". The point is the learning, which means the MVP has to reach real customers and measure something real. That sets the lower bound on what goes in: enough for a first customer to get the value, and enough engineering underneath that the learning doesn't stop when the first bug appears.

It also sets the upper bound. Every feature that doesn't help a first customer get the value delays the learning, so it waits.

Why is any single number a guess?

Because the variables are big and specific to you:

• How many distinct things a user must be able to do. Two core flows and ten are different projects.
• Who the users are. One kind of user, or several roles with different permissions and views.
• What it must connect to. Payments, an existing system, a partner's API, single sign-on for enterprise customers.
• What the data must survive. A demo dataset, or real customer data with audit, retention and deletion requirements.
• How much is already decided. A product with clear acceptance criteria moves faster than one being designed while it's built.
• How decisions get made. A founder who answers questions the same day is worth more speed than any framework.

Two founders asking for "a SaaS MVP" can differ by several times on each of these. So the question to ask isn't "what's typical?" but "what's the smallest version my first customer will pay for or use, and how long does that take?"

What time-boxes do product teams actually use?

Established methods don't estimate open-ended scope. They fix the time and shape the work to fit. Three are well documented by their authors:

None of these says how long your MVP takes. What they share is the more useful idea: decide how much time the problem is worth, then shape a solution that fits it. Basecamp calls this the appetite, and frames it as a different question from estimating: not "how much time will it take?" but "how much time do we want to spend?" Its authors describe six weeks as "long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start".

That is the right frame for an MVP. Pick the time you're willing to spend before you learn whether the product works, and make the scope fit it.

Do you need a design sprint before the build?

Sometimes. If you're still unsure whether customers want the product, five days of prototyping and testing with real people, as GV describes it, answers that more cheaply than any build. If you already have a first customer waiting and a clear job for the product, skip it and spend the time on scoping. The two answer different questions: the sprint asks "should we build this?", the scoping week asks "what exactly do we build first?"

How do you fix dates you can keep?

In my MVP Sprint, the first week is scoping, and the dates are fixed only at the end of it. In that week we:

1. Name the first customer and the one job they need the product to do.
2. List every feature anyone has asked for, then mark each one: does the first customer need it to get the value? Only the yes column is built.
3. Write acceptance criteria for each remaining feature, so "done" is a fact, not a feeling.
4. Decide the foundations: authentication and roles, the data model, the deploy pipeline, monitoring. These aren't optional and aren't negotiated away.
5. Fix the price and the dates for that written scope.

Everything in the "no" column goes on a written next-phase list. It isn't lost; it's sequenced. During the build, priorities can change within the agreed scope at any weekly demo. A change that adds scope is written down with its effect on price and dates before it's built, which is how the dates stay true.

What should never be cut to save time?

The parts that make the learning possible and the next phase cheap:

• Authentication and permissions done properly. Retrofitting roles into a product built for one kind of user is one of the most expensive rewrites there is.
• A data model designed for the next stage. Not over-built, but with the relationships and constraints the real business will need.
• Automated tests on the critical paths, money and permissions first.
• A deploy pipeline with staging and production, so shipping a fix is routine.
• Monitoring and alerts from the first deploy, so you hear about problems before your first customer does.
• A runbook and documentation, so a future hire or a reviewing investor can understand the system without you.

These feel slow in week two and save months later. They're the difference between an MVP and a prototype you'll rewrite.

What usually slows an MVP down?

In my experience, rarely the code. More often:

• Decisions that wait. A question that takes a week to answer costs a week.
• Scope that grows quietly. "While you're in there, could it also…" is how most dates slip.
• Designing while building. Screens with no agreed content or flow get built twice.
• Third parties. Approvals for payment providers, app stores or partner APIs have their own timelines. Start them in the scoping week.
• Data migration nobody planned. Importing a first customer's existing data is a project of its own.

What does a realistic plan look like?

One week of scoping that produces a written scope, a fixed price and fixed dates. A build with a demo on a staging URL every week. A launch with monitoring, a runbook and a handover. And a next-phase list you've already agreed, so the day after launch isn't a planning crisis.

If someone gives you a duration before they've asked who your first customer is, they're quoting an average. Ask them what's in it.

How I do this

The MVP Sprint is a fixed-price, fixed-scope build of a first production version, with dates fixed at the end of the scoping week and kept by writing down every change. If you're not yet sure what the first customer needs, an architecture review or a conversation through the contact page is the cheaper first step. For what a platform built this way looks like in production, the Exhibit Social case study covers a B2B platform I led from zero.