How We Scope an MVP in Two Weeks

Most initial briefs describe a solution. The first job is to work backwards to the problem, because the solution usually contains three or four features that exist for reasons nobody can articulate any more.

Days 1–2: the outcome conversation

We ask what has to be true for this to have been worth building, in the founder's own terms. Not "users can create an account" — something like "a technician can accept a job and get paid without phoning anyone". That statement becomes the constraint we test every feature against.

Days 3–4: the user journey, end to end

We walk the complete path for each role, including the boring parts: how someone finds out the product exists, how they get in, what happens when they abandon halfway, and what happens on the second visit. This is where forgotten requirements surface — almost always around identity, notifications, and what an administrator has to do manually on day one.

Day 5: the cut list

We list everything discussed and sort it into needed for the outcome, needed soon after, and assumed but not actually required. The third pile is usually 30 to 50 percent of the original brief. This is the single most valuable hour of the engagement.

The second week converts agreement into something engineers can act on without guessing.

Days 6–7: data model and roles

What are the core entities, how do they relate, and who is allowed to see and change what? Getting this wrong is the most expensive category of mistake because it is the hardest to change later. On the MEISTER workforce engagement this was deliberately the first substantial deliverable, precisely so later operational modules would not each invent their own identity rules.

Days 8–9: screens and states

Every screen, with its empty state, loading state, error state, and permission-denied state. Teams routinely specify the happy path and discover the other four during development, which is where estimates go wrong.

Day 10: integration and risk review

Which third-party systems are involved, what happens when each is unavailable, and which assumptions are unproven. Anything genuinely unknown gets flagged as a spike with a time box rather than being buried inside a feature estimate.

Four artifacts, all of which are useful independently of whether you build with us:

• A written specification covering roles, entities, screens, states, and rules. Prose and diagrams, not a backlog of one-line tickets.
• A milestone plan that sequences the build so something demonstrable exists early, rather than everything landing at the end.
• An estimate with its assumptions attached, so when something changes you can see which number moves and why.
• A risk list with the unknowns named and a proposed way to resolve each.

If a scoping phase does not produce something another team could pick up and build from, it has not finished.

Founders arrive focused on the number. The number is downstream of scope, and scope is where the leverage is.

Removing a feature during scoping costs an hour of discussion. Removing it after it is built costs the build, the tests, the review, and often a data migration — and it will not be removed, because nobody deletes work that has already been paid for. It stays, gets maintained, and slows everything around it.

The pattern we see repeatedly: the features cut in week one were the ones the founder was least able to explain the purpose of. That is not a coincidence. A feature nobody can justify concisely is usually a solution to a problem that was never confirmed.

If you want to run a version of this yourself, these five questions surface the most:

1. What does the user do today instead? If the honest answer is "nothing, this is not a real problem for them", stop.
2. Who is the first person to use this, by name? Abstract users produce abstract products.
3. What has to happen manually on day one? Every product has an operations tail. Naming it early prevents building automation nobody needs yet.
4. What would you cut if the budget halved? Ask it before you know the budget, and the honest ordering appears.
5. How will you know within a month whether this worked? If there is no answer, the product has no target and scope will expand forever.

Two weeks is the right length for a product with a clear user and a conventional technical shape. It is not enough when:

• There is genuine technical uncertainty — an AI capability that may not reach the required quality, or hardware that has not been validated. These need a time-boxed feasibility spike first.
• The regulatory position is unclear. Health and financial products often need a compliance answer before the product shape can be settled.
• The founding team disagrees about the product. Scoping surfaces this quickly but cannot resolve it, and building through an unresolved disagreement is the most expensive path available.

In each case the right move is a short, explicit phase to remove that specific unknown, then scope. Not scoping around it and hoping.