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

The short answer: 8–12 weeks

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

1. Fix the scope and the price before design starts.
2. Ask for a preview link every week, not a status report.
3. Answer questions within a day.
4. Start store accounts and payment applications in week one.
5. 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.

This is the method we use in the first week of every project. You can run it yourself with a notebook before you talk to any developer.

Start with one user and one job

Most first versions are too big because they try to serve everyone the founder has ever spoken to. Pick one kind of user and the one job they would hire your product to do.

Write it as a single sentence:

A landlord with two or three flats lists a room and receives enquiries from verified tenants.

If the sentence needs the word "and" more than once, you are describing two products. Choose the one whose users you can reach this month.

This idea is older than software. Eric Ries describes a minimum viable product as the version that lets a team collect the most learning about customers with the least effort, in The Lean Startup. The scope follows from the thing you want to learn.

Write down what you need to learn

Before listing features, list the two or three things that must be true for the business to work. For a rental marketplace they might be:

• Landlords will list a room without being phoned by a salesperson.
• Tenants trust a listing enough to send a message.
• Somebody will pay for a featured listing.

Each feature now has a test to pass: does it help prove or disprove one of these? A dark mode does not. A way for tenants to message landlords does.

List every screen, then sort them

Now walk through the product as your one user, from the first visit to the moment the job is done, and write down every screen they touch. Do the same for the person on your team who will run it, because an admin panel is part of an MVP too.

Sort every screen and feature into three groups:

Be strict about the third column. Features in it are not rejected. They are waiting for evidence.

Cut by asking what you can do by hand

The fastest way to shrink an MVP is to do things manually at first. Ask of every feature in the "must launch" group: could a person do this by hand for the first fifty customers?

• Verification can be a team member checking documents in the admin panel, not an automated identity service.
• Payouts can be a weekly bank transfer, not a payments integration.
• Recommendations can be a hand-picked list, not an algorithm.

Manual steps do not scale, and that is fine. You are buying information, and you will rebuild the parts that prove they matter.

Decide what the first version must not skip

Cutting scope is different from cutting quality. Some things are cheap to do properly at the start and expensive to add later:

1. Sign-in and permissions. Who can see and change what.
2. A phone-sized layout. Most of your first users will arrive on a phone.
3. Analytics and error tracking. Without them you launch blind and learn nothing.
4. Ownership. The code, the domain and every account should be in your name from day one.

We keep these in every build, however small. You can see them in the projects on our work page, such as the Rehnaa rental marketplace, which launched with map search, chat and landlord verification and left everything else for later.

Turn the list into a fixed price

A scope is finished when someone can quote for it. At the end of the week you should have:

• A feature list with the three groups above.
• A map of every screen and how they connect.
• The things you will do by hand at first.
• A fixed price and a launch date for the "must launch" group.

If a developer cannot give you a fixed price from that, the scope is still too vague. Go back to the screen list and fill in the gaps.

This is exactly what the blueprint week in our MVP development process produces, and why we can agree the price before design starts.

Common mistakes when scoping an MVP

Building for investors and not for users. A demo that impresses in a meeting is not the same as a product ten people use every week. Scope for the ten people.

Launching on every platform at once. A web app that works well on phones is often enough to test the idea. Add native apps when users ask for them, or start with the phone app if the product only makes sense in a pocket.

Treating the first version as final. It will change. Scoping an MVP well means the second version is shaped by what users did, not by what you guessed.

A one-page checklist

• One user, one job, in one sentence.
• Two or three things you need to learn.
• Every screen listed for the user and for your own team.
• Each feature marked: must launch, launch if cheap, version two.
• Manual stand-ins chosen for anything expensive.
• Sign-in, phone layout, analytics and ownership kept in.
• A fixed price and a launch date.

If you would like a second pair of eyes on your list, send it to us. We will tell you what we would cut.