“Minimum viable product” is one of the most quoted and least followed ideas in software. In practice, MVPs tend to fail in one of two ways. Either they are so minimal that they prove nothing, or they quietly grow into version 1.0 with a year of features nobody has asked for yet. Both waste the one resource an early product cannot replace: time to learn.
Here is the method we use with founders and product teams to scope a first version that is small, shippable and still answers a real question.
Name the assumption you are testing
An MVP is an experiment, and an experiment needs a hypothesis. Before any feature list, write down the riskiest assumption behind the product. Usually it is one of these:
- Demand: the people we have in mind have this problem badly enough to change how they work.
- Value: our way of solving it is clearly better than what they do today, including doing nothing.
- Willingness to pay: they, or their company, will pay a price that makes the business work.
- Feasibility: we can actually deliver the result, for example with acceptable AI accuracy or data we can legally access.
Pick the one that would kill the product if it turned out to be false, and scope the MVP to test that. A product whose biggest risk is willingness to pay needs a checkout and a price page in its first version. A product whose biggest risk is feasibility might need no user interface at all, just a pipeline that proves the result is good enough.
Draw the single path that must work
Next, describe the one journey a user must be able to complete for the test to mean anything. Not the whole product: one path, from first contact to the moment of value.
For a B2B scheduling tool that might be: a manager signs up, imports their team, publishes a rota, and employees see their shifts on their phones. Everything on that path has to work properly. Everything off that path is a candidate for later.
Writing the path down as a short story, screen by screen, is also the fastest way to discover that two people on the team had different products in mind.
Decide what to fake
A surprising amount of an early product can be done by hand or with existing tools, as long as the user does not experience it as broken:
- onboarding done by a person over a call instead of a self-service wizard;
- reports sent as a spreadsheet or PDF instead of an analytics dashboard;
- billing through invoices or a hosted payment link instead of a full subscription system;
- an admin panel built on an off-the-shelf tool instead of a custom back office;
- integrations handled with a scheduled export instead of a real-time API.
Each of these saves weeks. Each also tells you something: if customers keep asking for the self-service version, you know what to build next.
What never to cut
Being minimal on scope is different from being careless on foundations. Some things are expensive to add later and cheap to do right from the start:
- Authentication and permissions done with a proven provider, not a homemade login.
- A data model that matches the business, especially around accounts, organisations and roles. Multi-tenant assumptions are painful to retrofit.
- Basic security and privacy hygiene: encrypted connections, secrets out of the code, personal data handled with GDPR in mind.
- Analytics on the one path, so you can see where people drop off. Without it the experiment has no result.
- Automated deployment, so that shipping a fix takes minutes and nobody is afraid of releasing.
- Accessibility and performance basics, which cost little in a new codebase and a lot in an old one.
Choose boring technology
An MVP is not the place to try three new frameworks. Choose a stack the team knows well and that will still be a sensible choice if the product succeeds: for many SaaS products that means TypeScript with React or Next.js, a managed PostgreSQL database and a mainstream cloud. The aim is that a successful MVP becomes the foundation of the product, not a prototype you have to throw away under pressure.
Set the timebox before the scope
Fix the time first, then fit the scope into it. A few weeks to the first real users is a healthy target for most B2B MVPs. If the path you drew does not fit, cut along the path, not across it: simplify steps, fake more, narrow the audience. Do not ship half of every feature.
Agree in advance what result would count as success, what would count as failure, and what you will do in each case. That turns a launch into a decision instead of a mood.
After launch: learn, then build
The most valuable output of an MVP is not the code but what you learn in the first weeks of use. Talk to every early user you can. Watch the analytics on the path. Keep a short list of what people ask for and how often. Then plan version two from evidence.
If you are preparing a new product, our SaaS and MVP team can run a short discovery with you, define the path and the experiment, and build the first version with the foundations above in place. Our UX and UI designers prototype the path before a line of code is written. Tell us about your idea.