How long does it take to build an MVP

The number of weeks follows the scope, the same way the price does. Two founders can ask for "a simple app" and be six weeks apart, because one of them means a single dashboard and the other means a marketplace with payments between buyers and sellers. So the useful question is not how long an MVP takes, but how long yours takes, and which decisions are making it longer.

This article is part of my guide to how to build an MVP. For what those weeks cost in pounds, see what an MVP costs in the UK.

Where the weeks go

Every MVP goes through the same five stages, whether one person does it in a month or an agency does it in a quarter. The stages that get skipped come back later, usually at a worse time.

1. 1

   Scoping, a few days to 2 weeks

   Who the first user is, the one job the product does for them, and the short list of features that job needs. Skipping this is the most expensive way to save a week.

2. 2

   Design, 1 to 2 weeks

   User flows first, then the screens. Clickable in Figma before code, so changes cost minutes instead of days.

3. 3

   Build, 3 to 6 weeks for a focused web MVP

   Sign-in, the core workflow, the database, payments and the admin you actually need.

4. 4

   Testing and fixes, about a week

   Real devices, real data, the unhappy paths: wrong passwords, failed payments, empty screens.

5. 5

   Launch, a few days

   Domain, hosting, email sending, analytics and the legal pages. Longer if an app store is involved.

Those ranges are for one experienced person, or a small team that works like one, on a web app with one type of user. They stretch when the product has more moving parts, and they stretch a lot when decisions are still being made during the build.

Timelines by type of MVP

These are build ranges, after scoping. The agency column comes from a UK agency's published figures. The other two columns are my estimates, not survey data: the one-person column is the range I quote for my own MVP Build, and the AI builder column is my rough view of what a founder can get to on their own. Treat them as a starting point for a conversation rather than a promise.

Rocking Tech, a UK agency, publishes a three week Platform Discovery Sprint, eight to twelve weeks of build for a single-platform web MVP in the £15,000 to £30,000 bracket, and ten to sixteen weeks for the £30,000 to £60,000 bracket where it says most funded UK startups land. Agency timelines are longer partly because there are more people and handovers, and partly because agency MVPs tend to be bigger.

Real examples

Public timelines for real MVPs are rarer than you would think, and the ones that exist are usually told by the founder after it worked. Two that are well documented:

Buffer, about seven weeks. Joel Gascoigne tested demand first with a two-page site: a landing page and a sign-up. Then he added a pricing page in the middle to see whether anyone would click on a paid plan. Only after that did he build the product, in evenings and weekends over seven weeks, with a self-imposed deadline. He cut a guided sign-up flow he considered vital to hit that date. The first paying customer arrived four days after launch.

Product Hunt, about 20 minutes, then a long weekend. Ryan Hoover started it as a daily email list using a tool called Linky Dink and told The Next Web the setup took 20 minutes. The first version of the website came later, built with Nathan Bashaw over Thanksgiving.

Neither of those is a typical build. Both are typical of how good MVPs start: test the demand with the smallest possible thing, then build the version that the test justified. For more of these, see MVP examples and what they launched with.

What adds weeks

The things that push a build from four weeks towards twelve are mostly decisions, not code.

• Scope that changes during the build. Every new idea mid-build means redesign, rework and retesting. It is the most common reason MVPs run late.
• Designs worked out in code. If nobody agreed the screens first, they get designed during the build at build speed, often twice.
• A second or third type of user. Each role needs its own sign-up, screens and permissions. A marketplace is two products sharing a database.
• Money moving between parties. Taking a card payment is a small job. Splitting it, holding it or refunding it properly is not.
• Native apps on day one. More platforms to build and test, plus app store review.
• Slow decisions. A question that waits three days for an answer costs three days. One decision-maker who replies the same day is worth more than any framework choice.
• Integrations with old or poorly documented systems. A well documented API takes hours. A legacy system with no sandbox can take weeks.

What saves weeks

The reverse list is just as useful:

• One user type and one core job for the first version.
• Doing the awkward step by hand. A manual approval, an emailed invoice, a spreadsheet instead of an admin panel. Paul Graham's essay on doing things that don't scale is full of founders who did this on purpose.
• Stripe Checkout or Payment Links instead of a custom payment flow.
• A web app that works on a phone instead of native apps, until you know people want it.
• A fixed appetite. Basecamp's Shape Up method sets the time budget first and lets the scope flex to fit it, rather than estimating a fixed scope and watching the date slip. Their big batch projects are six weeks.

The features to cut from an MVP article goes through these one by one.

App store time

If your MVP is a native app, the build is not the last step. Apple says App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, and that incomplete submissions take longer.

Google Play is slower for new developers. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, each opted in for at least 14 consecutive days, before they can apply for production access. Google also says some apps get a longer review, of up to seven days or more in exceptional cases.

So a native MVP needs two to three weeks of store time built into the plan before launch day. A web app needs none, which is one reason I usually suggest a web app first.

A realistic six week plan

This is roughly how a focused web MVP fits into six weeks when scope is agreed before the build. It is the shape of my MVP Build, which typically takes 4 to 6 weeks from a fixed scope.

Week	What happens	What you see
1	Flows and screens designed, scope fixed	Clickable prototype
2	Sign-in, database, core screens	First preview link
3	The core workflow end to end	A working happy path
4	Payments, email, admin basics	Test payments in Stripe
5	Unhappy paths, mobile, testing	A build to try on your phone
6	Fixes, launch setup, handover	Live on your domain

If the idea is still loose, add one or two weeks of scoping and a clickable prototype at the start. That is what the Validation Sprint is for, and it usually saves more time than it takes.

How to get your own number

Start by cutting the scope down to the first version, then price and time it.

1. Write down the first user and the one job, then list features and cut anything that does not serve that job. The guide to scoping an MVP in an afternoon walks through it, and the MVP scoping tool does it for you.
2. Run the short list through the MVP cost calculator, which gives a price range and a rough number of weeks for each route.
3. When you ask for quotes, ask for a date and a list of what is in and out. If you are choosing between a fixed quote and a day rate, read fixed price vs day rate first, because the pricing model changes who carries the risk of a slipped timeline.