An MVP in Eight Weeks: What Fits, and What Has to Be Cut

Eight weeks is a realistic timeline for the first version of a product, but only on one condition: a single core scenario is fixed before development starts. Not five user roles, not “an account area with everything you need”, but a concrete path — who opens the app, why, at what moment, and what has to happen next.

Weeks 1–2. Discovery and Locking the Scope

Interviews with the client and future users, a description of the core scenario, a screen map, a list of integrations, a success metric. The output is a document with a separate section listing what the first version will not include. That list is what saves the project in week six.

The stack and the infrastructure are decided here too — on the basis of requirements, not the team's habits.

Weeks 3–5. Design and Parallel Development

Design runs a week ahead of development: while the first screen is being built, the third is being drawn. The backend starts from API contracts — agreed before implementation, so that the frontend and the mobile app are never left waiting.

A feature that cannot be explained in one sentence does not belong in the MVP. It belongs in the next release, if the data confirms the need.

Weeks 6–7. Assembly, Integrations, Testing

The most underestimated phase. Integrations with payments, notifications and external services almost always take longer than planned, because they depend on other teams and other people's deadlines. In parallel: testing the core scenario on real devices and preparing the infrastructure — domains, certificates, monitoring, backups.

Week 8. Launch and the First Data

Release, store publishing (budget time for review), analytics wired up, training for the client's staff. From day one you collect data: does the user reach the target action, where do they drop off, what do they look for and fail to find.

Four Decisions That Set the Timeline

1. One scenario instead of three. Every extra role doubles the testing surface.

2. Off-the-shelf instead of in-house. Authentication, notifications, file storage — take what already exists and write only what makes up the essence of the product.

3. One decision-maker on the client's side. Approval by committee adds two weeks or more to the timeline.

4. A separate “after launch” backlog. Good ideas are not rejected — they are written down and wait for data.

An MVP is not a stripped-down product but an instrument for testing a hypothesis. Its job is not to please everyone, but to show as quickly as possible whether the next six months are worth investing in it.