What a 6-week MVP actually includes, week by week

Six weeks sounds either impossibly short or suspiciously long, depending on who you ask. It is neither. It is enough time to build one job, done well, for one kind of user, and put it in production. It is not enough for anything else, and most of the skill is in holding that line.

Before week one: the scope

The six weeks do not start with a blank page. Most of our projects begin with a paid two-week discovery sprint that ends in a written scope, a fixed timeline, and a prototype you can click.

That matters because the expensive decisions are already made when the build starts. Who the user is. What the one job is. What is out. A six-week build that is still arguing about scope in week three is a ten-week build.

The six weeks

1. Week 1

   Foundations

   Repositories, environments, a deploy pipeline, sign-in, and the data model. By the end of the week something is deployed to production, even if it does nothing yet. Shipping to an empty app early removes the worst surprise from week six.

2. Week 2

   The core flow, end to end

   The one job the product exists for, working from first screen to last. It is ugly and it skips every edge case. The point is to prove the whole path connects before polishing any part of it.

3. Week 3

   The core flow, properly

   Validation, error states, empty states, loading states. What happens when the network drops halfway. This is the week the product stops being a demo.

4. Week 4

   What makes it a business

   The pieces the core flow needs around it to be usable for real: payments, notifications, or a basic admin view. Usually one or two of these, rarely all three.

5. Week 5

   Hardening

   Real data, real devices, slow connections. Analytics on the core flow so you can see where people stop. Monitoring, backups, and a fix list worked from the top.

6. Week 6

   Launch

   Production release with a rollback plan, then the first real users. The week ends with the product live and a short list of what those users tripped on.

What you see each week

Every week ends with something you can click, on a real URL or a real device. Not a status deck. If a week ends and there is nothing new to try, something has gone wrong and you should hear about it that day, not at the end.

What is not in it

The list of things left out is as much a part of the scope as the list of things included. A typical six-week build does not have:

• A second type of user with their own flows.
• Native apps on both platforms. Pick one, or ship on the web first.
• Settings pages for things nobody has asked to change.
• Custom reporting. An export and the analytics dashboard cover the first months.
• Integrations with tools your first users do not use yet.

None of these are bad ideas. They are week-seven ideas, and they are much easier to judge once real people are using the thing.

When six becomes nine

We quote six to nine weeks, and the scope document says which. The extra weeks come from a short list of causes.

• Payments that need reconciliation, refunds, or payouts, not only a checkout.
• Two sides that both need a product, such as buyers and sellers.
• Offline use, where the app has to work without a connection and sync later.
• Someone else's clock: app store review, payment provider onboarding, a partner's API access.

What an MVP is for

An MVP is not the small version of the product you have in your head. It is the first version that can be wrong in useful ways, in front of people who will tell you. Six weeks is about how long it takes to earn that.