Most first versions fail for the same reason: they try to be a smaller copy of the whole product instead of a test of one idea. This article walks through how we build an MVP with a client — starting from the riskiest assumption, cutting everything that does not test it, and deciding up front what result would tell you to continue, change direction or stop.
Start with the riskiest assumption
Write down what has to be true for the product to work — people have this problem, they will pay for this, this workflow can be automated — and pick the one you are least sure about. The MVP exists to test that one thing. Everything else waits.
Cut features, not quality
A short list of features that work well beats a long list that half works. Users forgive a missing feature; they do not forgive a broken one. Keep the scope to the screens the test needs, and build those properly.
| Assumption to test | What the MVP needs | What it can skip |
|---|---|---|
| People have this problem | A landing page and a waitlist | Any product at all |
| They will pay for it | One purchasable plan and a checkout | Self-serve onboarding, settings |
| The workflow can be automated | One end-to-end path with real data | Every edge case, admin tooling |
Decide what success looks like before you build
Agree the numbers in advance. Without a target, every result looks like progress and nothing gets decided. A useful target has three parts:
- A metric that the assumption directly moves — sign-ups, completed orders, second-week returns.
- A threshold agreed before launch, written down where everyone can see it.
- A date by which the number is read and a decision is made.
The MVP that told us the most was the one we were most embarrassed to ship. It answered the question in three weeks.
Founder, early-stage marketplace
Plan the second version on day one
An MVP that works will need to grow. Choose a stack and a data model that can carry the next twelve months, even if the first version only uses a fraction of it. Rewrites are expensive; extensions are cheap. One habit that helps: keep a short, plain-text list of what you deliberately left out, next to the code.
# Deferred on purpose
- Multi-currency pricing (test is INR-only)
- Team accounts (test is single-user)
- Email digests (test is in-app only)Which assumption is usually the riskiest for a new product?
Choose an answer to see the results.Whatever you answered, the useful move is the same: build the smallest thing that finds out, and agree what you will do with the answer before you have it.