How to scope an MVP in one week (without cutting the wrong corners)

Most MVPs fail before a single line of code is written. Not because the idea is bad, but because the scope is wrong — too big to ship, too small to learn from, or aimed at the wrong risk entirely. After scoping a few dozen of these with founders, I have stopped treating the MVP as a small version of the product. It is not. It is a purpose-built instrument for buying information, and once you frame it that way the cuts get obvious.

Here is the seven-day process, day by day.

Day 1: name the one risky question

Every startup has exactly one assumption that, if wrong, kills the company. Payment willingness. Technical feasibility. Distribution. Retention. You probably already know which one it is — it is the one you keep avoiding in pitch conversations.

Write it down as a single sentence in the form *"We believe X will Y when Z."* That sentence is the only thing the MVP exists to test. Tape it above your monitor. Every feature decision for the rest of the week gets measured against it.

Why "one" matters

Multiple hypotheses produce multiple feature trees, and multiple feature trees produce a small product instead of a sharp test. When you discover you have three risky questions, pick the one that kills the company fastest if wrong. The other two will still be there next month.

Day 2: pick the shape

The shape of an MVP is the surface it lives on. Same question, different shape:

• A landing page with a waitlist and a fake checkout
• A Telegram bot that gates a workflow behind a one-question form
• A single-flow React app with no nav and no account
• A Notion page wired to a Stripe link
• A Loom video and a Calendly link

The shape matters more than the stack. A landing page can validate payment willingness in two days. A web app testing the same thing takes three weeks. Pick the laziest shape that can still answer the question honestly.

Day 3: write the cut list

This is the day most founders fight me. We sit down with the feature wishlist and I draw a line through anything that does not test the question. Common casualties:

• Accounts (unless identity is the risk)
• Dashboards (unless the workflow is repeated)
• Admin panels (you are the admin; use the database)
• Notifications (unless the loop is the product)
• Settings (defaults are a feature)
• Mobile responsiveness past "does not break on phones"

The cuts are not permanent. They are deferrals. Everything you remove from the MVP is something you get to add with evidence instead of with hope.

Day 4: build the spine

Day 4 is for the one path through the product. Not the happy path — the *only* path. Hardcode anything that is not the test. Stub anything you can stub. If a stranger can complete the action and you can see the result, the spine is done.

Day 5: instrument it

An MVP without measurement is a product launch in costume. Before you show anyone, wire up:

1. A page-view event on entry
2. An event on the action that proves the hypothesis
3. A way to talk to the people who did the action
4. A way to talk to the people who did not

The fourth one is the most valuable and the one teams skip the most.

Day 6: show five strangers

Not friends. Not investors. Five people who match the user you wrote on day one. Watch them on a call. Do not narrate. Do not help. Take notes on where they pause, not what they say afterwards.

Day 7: decide

You have the data. The hypothesis was supported, contradicted, or — most commonly — partially right in a way that reshapes the question. Whatever the answer is, write the new one-sentence hypothesis and start day one again.

You are not building the product. You are buying information. The faster you buy it, the more runway you keep, and the more your next decision is grounded in something a stranger actually did.