Founders usually arrive with a feature list and ask how much of it fits the budget. That's the wrong question. The right one: which single assumption, if wrong, kills the business — and what's the least we can build to test it?
- Write the riskiest assumption as a sentence you could prove wrong.
- Map the one user journey that tests it, end to end.
- Cut everything outside that journey; fake what's inside but expensive.
- Set the success threshold before launch, not after.
Start from the riskiest assumption
Every product rests on a few bets: people have this problem, they'll switch from their current workaround, they'll pay this much. Rank them by how likely they are to be wrong and how fatal that would be. The MVP tests the top one.
Takeaway
If you can't write down what result would make you stop, you're not building an MVP — you're building version one.
Keep one journey, end to end
Draw the path a user takes from first contact to the moment of value. That path must work completely — a half-finished journey tests nothing. Everything off that path (settings, admin tools, notifications, a second user role) waits.
Fake the expensive parts
Inside the journey, some steps are costly to automate but cheap to do by hand. Matching algorithms can be a person with a spreadsheet for the first fifty customers. Payments can be an invoice. Users don't care how the value is delivered, only that it is.
| Build properly | Fake for now |
|---|---|
| The core interaction users come for | Admin panels and internal tools |
| Sign-up and onboarding | Automated matching or recommendations |
| Anything that touches user data | Billing, invoicing, plan changes |
Decide the threshold before you ship
Set the number that means “keep going” before launch: 20% of trial users return in week two, three of ten pilots convert to paid. Deciding afterwards turns every result into a reason to continue.