How long does it take to build an MVP? A weekly plan

How long does it take to build an MVP? For most first products, eight to twelve weeks from the first call to launch day. A build takes less time when the product is a single web app, and more when it needs a web app, two mobile apps and several integrations on day one.

Here is what happens in each of those weeks, and what moves the date in either direction.

The short answer: 8–12 weeks

Stage	Weeks	What you have at the end
Blueprint	1	A feature list, a map of every screen and a fixed quote
Design	2–3	A prototype you can click through on your phone
Build	4–11	A working product, with a new preview link each week
Launch	8–12	The product live on your domain and in the app stores

The build is the part that stretches. Four weeks is enough for a focused web app. Eight is normal when there is a mobile app as well.

Week 1: the blueprint

The first week has no code in it. It turns the idea into decisions: who the first user is, which screens exist, what is left for later and what the whole thing costs.

This week sets the length of every week after it. A feature that is cut here costs nothing. The same feature cut in week seven has already been designed and half built. We have written a separate guide on how to scope an MVP if you want to do this part yourself.

Weeks 2–3: design

Every screen is designed for a phone and for a laptop, then linked into a prototype you can tap through. It looks like the product, and nothing behind it works yet.

It is far cheaper to change a drawing than to change code, so this is the time to show the prototype to a few future users. Two weeks is enough because the screen list was fixed in week one.

Weeks 4–11: the build

The front end, the API and the database are built together, a slice at a time: sign-up first, then the main job the product does, then payments and the admin panel.

You should not have to wait until the end to see it. We send a fresh preview link every week, so you can open the real product on your own phone and say what is wrong while it is still easy to fix.

How many weeks the build takes depends mostly on three things:

How many platforms. A web app alone is the fastest. iOS and Android from one codebase (React Native or Flutter) add less than building each one separately.
How many integrations. Payments, maps, email and accounting each bring their own testing and approval steps.
How many kinds of user. A marketplace with buyers, sellers and admins is three products that share a database.

Launch: the last week

Launch is a week of small jobs: moving to the live servers, connecting the domain, switching on analytics and error tracking, and sending the apps to the stores.

Both stores review an app before it goes public. Plan for the review, and for at least one round of changes, by submitting a few days before the date you have promised anyone. Apple explains what its reviewers check on the App Review page.

What makes an MVP take longer

Changing the scope during the build. Every new feature after week one moves the date. Write new ideas on a version-two list and keep going.

Slow feedback. If a question waits four days for an answer, the week is gone. Agree at the start who answers questions and how quickly.

Waiting on other companies. Payment providers, app stores and banks all have approval steps. Start those applications in week one, not week ten.

Content that is not ready. Text, photos, prices and legal pages often arrive last. Give them a deadline like any other part of the build.

What makes it faster

One user and one job. The narrower the first version, the sooner it ships.
Doing some things by hand at first. Verify the first customers yourself before paying for an automated service.
Proven tools. A common stack (React, Node.js, PostgreSQL) means fewer surprises and more ready-made parts.
One team. When design, web, mobile and backend sit together, nothing waits for a hand-over.

Can an MVP be built in four weeks?

Sometimes. A single-purpose web app with sign-in, one main screen and a simple admin panel can launch in about a month. The risk in a very short build is not the code. It is skipping the blueprint and the design, then discovering in week three that the product is solving the wrong problem.

Does a longer build mean a better product?

No. After about twelve weeks, a first version is usually no longer an MVP. It is a guess that is getting more expensive. The point of launching early is to let real users decide what to build next.

How to keep your build on schedule

Fix the scope and the price before design starts.
Ask for a preview link every week, not a status report.
Answer questions within a day.
Start store accounts and payment applications in week one.
Keep a version-two list, and put every new idea on it.

That is the process on our MVP development page: a fixed price after week one and a launch in 8–12 weeks. If you want a date for your own product, tell us what you are building and we will come back with a plan.