Most failed MVPs do not fail because the team built badly. They fail because the team built too much. An MVP is not a small version of your product – it is the smallest thing that can prove or disprove the riskiest assumption in your business. This guide covers how to find that assumption, what to build around it, and what to leave out no matter how tempting it is.
Start with the assumption, not the feature list
Every startup rests on a stack of assumptions. Some are safe: people use smartphones, businesses want to save money. Some are not: restaurant owners will pay a monthly fee to manage their own delivery drivers. That second kind is what your MVP exists to test.
Write down every assumption your idea depends on. Sort them by two questions: how badly does the business break if this is wrong, and how confident are we really? The assumption that scores highest on damage and lowest on confidence is your riskiest one. Build the smallest thing that tests it.
The one-journey rule
A useful constraint: your MVP should support exactly one complete user journey, end to end, done properly. Not five journeys done at 60 percent.
For a marketplace, that journey might be: find a listing, book it, pay, get a confirmation. Not: browse, filter, save favourites, message the seller, negotiate, book, pay, review, refund. The second list is a product. The first is a test.
If a feature does not sit on that single journey, it is not in the MVP. This is a harder rule to follow than it sounds, because every feature you cut has a plausible reason to exist.
What to build
- The core loop. The thing users come back to do. If they cannot do it smoothly, nothing else matters.
- Enough onboarding to get someone to the core loop. Often this is just email sign-in. Sometimes it is nothing at all.
- Instrumentation. If you cannot see what people did, you have not run an experiment, you have shipped software into the dark. Analytics is not a “phase two” item.
- A way to talk to users. A support email, an in-app prompt, a Calendly link. The qualitative signal is usually more valuable than the numbers at this stage.
What to cut
Admin panels
You have twenty users. You can manage them from the database, a spreadsheet, or a no-code tool. A custom admin panel is weeks of work that no customer will ever see.
Multiple user roles
Role-based permissions multiply the surface area of everything – the UI, the backend, the QA. Pick your primary user. Serve the second role manually until the first one is proven.
Settings screens
Every toggle is a decision you are pushing onto the user and a code path you now have to maintain. Choose sensible defaults instead. You can add preferences once you know which ones people actually ask for.
Scale infrastructure
Microservices, sharded databases, and multi-region deployment solve problems you do not have. A single well-structured application on a managed platform will carry you far further than most founders expect. Premature scaling architecture is one of the most expensive mistakes in early-stage software.
The second platform
Ship where your users are. Learn. Then port.
The things people cut that they should not
Some corners are more expensive than the thing they save.
Error states. The happy path is the easy part. What happens when the payment fails, the network drops, or the upload times out is what determines whether someone trusts your product. A polished app that handles failure badly still feels broken.
Performance. Slow is a feature-level problem. Users do not file a bug report about a three-second load, they just leave.
Basic security. Authentication, input validation, and sensible data handling are not optional at any stage. A breach at twenty users is still a breach.
Design quality on the core loop. You can ship a plain settings page. You cannot ship a confusing checkout.
Knowing when the MVP has done its job
Decide the success criteria before you launch, in writing, with numbers. “We will consider this validated if 30 percent of signups complete the core action in week one and 15 percent come back in week two.” Without a threshold set in advance, every result looks encouraging enough to keep going, which is how teams spend two years building something nobody wanted.
An MVP that fails cleanly and quickly is a good outcome. It cost you three months instead of three years.
Where to go from here
The hardest part of MVP scoping is not technical – it is the discipline to leave good ideas out. That is easier with someone outside the team asking why each feature is on the list.
Our product strategy and discovery work exists to do exactly that before development starts. If you are scoping a first build, tell us what you are trying to prove and we will help you find the smallest thing that proves it.
