A minimum viable product should test a specific business assumption through the smallest credible user experience, rather than reproduce a finished app with fewer features. For founders commissioning their first build, this means defining the evidence required, protecting the core workflow and limiting spending until real users demonstrate value.
Key takeaways
- Start with the riskiest assumption about customer behaviour, then choose the smallest test capable of producing useful evidence.
- Scope one complete user journey, keeping features only when they help users reach the outcome being tested.
- Set success criteria before development begins, including what would justify further investment and what would trigger a rethink.
- Budget for recruitment, support and iteration as well as development, so the first launch does not exhaust available cash.
- Use observed behaviour and repeat usage to guide the next release, rather than collecting feature requests without context.
What is a minimum viable product?
A minimum viable product is the smallest usable version of an app that tests a significant business assumption with real users. It provides enough of the core experience to reveal whether the intended audience receives value, without building the full product vision.
Its purpose is learning that supports an investment decision. A scheduling app might need to show that independent tutors will send booking links and receive appointments through them. It does not initially need every calendar preference, reporting view or team management option.
Minimum does not mean unfinished in ways that undermine the test. If bookings disappear or confirmation messages are unclear, poor results may reflect delivery problems rather than weak demand. The product needs to be dependable within a deliberately narrow boundary. Equally, an early prototype may be sufficient to test comprehension before a working app is justified.
Which assumption should the MVP test first?
A feature list is a poor starting point. Before estimating development, founders should identify what must be true for the business to work and which belief has the least supporting evidence.
That might concern demand, willingness to pay, a supply constraint or the practicality of a workflow. Each requires a different test. Interviews can expose problems and existing workarounds, but positive comments do not establish that someone will change their behaviour or pay for a solution.
Write the assumption as an observable statement: independent tutors who currently arrange lessons through messages will use a shared booking link for new enquiries. This is more useful than saying that tutors need better scheduling software.
- Define a narrow audience with a recognisable problem and an existing way of handling it.
- Identify the behaviour that would indicate the proposed solution is useful.
- Choose the least expensive credible way to observe that behaviour.
- State what evidence would support, weaken or leave the assumption unresolved.
Sometimes the next step is a manually delivered service, not an app. A concierge test can reveal whether the proposed outcome matters before development begins. However, it will not prove that customers can complete a self-service workflow; that needs its own test.
How do founders decide which features to include?
Map the shortest complete journey from a user's starting point to the promised result. For the tutor example, that could mean setting availability, sharing a link, accepting a booking and receiving confirmation. Every proposed feature should have a clear relationship to that journey or the evidence being collected.
Classify features into three groups:
- Required for the test: capabilities without which the user cannot complete the core task or the team cannot assess the result.
- Required for responsible operation: proportionate access controls, necessary data handling, recovery paths and visibility of failures.
- Deferred: improvements that may become valuable but do not determine whether the initial proposition works.
Authentication belongs in scope when users need private accounts or persistent records. Payment integration belongs there when collecting payment is central to the test. Neither should be included automatically. An account requirement can introduce friction where a simple public interaction would suffice.
A smaller scope is useful only when the remaining experience still produces evidence that can support a business decision.
Put deferred ideas into a later-release backlog, with the reason for postponement. Advanced filters, referral schemes and extensive dashboards often belong there. A feature can return when user evidence justifies it; deferral is not a permanent rejection.
How can an MVP budget avoid unnecessary spending?
Budgeting should cover the learning cycle, not just the first release. Founders need room for user recruitment, basic analytics, support, maintenance and changes after launch. Spending everything on development leaves no capacity to respond when the first cohort encounters a problem.
A capped discovery phase can make the build estimate more useful. The output should include the core journey, acceptance criteria, major dependencies and explicit exclusions. External integrations deserve particular attention because access restrictions, incomplete documentation or unsuitable data can change the scope.
Separate necessary foundations from future architecture
Clear data structures, maintainable code and appropriate access restrictions are sensible foundations. Building elaborate infrastructure for hypothetical scale is different. Technical decisions should reflect expected initial usage and the consequences of failure, while recording where later changes may be necessary.
Existing services can reduce work on non-core functions such as transactional email or payments. Their ongoing fees, limitations and integration costs still belong in the budget. A short build window can encourage focus, but it should not replace an estimate grounded in the actual workflow.
For agency-led projects, agree how scope changes are handled. A new feature should usually replace another item, increase the budget or move to a later release. Quietly absorbing additions makes delivery dates and cost forecasts unreliable.
What should be measured before and after launch?
Success criteria should be written before development starts. They need to identify the audience, the action that demonstrates value and the period over which that action will be observed. The right measures depend on how often the underlying problem occurs.
For a booking tool, useful evidence might include tutors publishing availability, sharing their link and receiving genuine bookings. Account creation is an intermediate step, not the outcome. A large registration count can conceal a product that few people actually use.
Track completion through the core journey and investigate where people stop. Pair those observations with short interviews about what happened, what users expected and what they did instead. Analytics shows a pattern; conversations can help explain it.
Small early cohorts require care. A handful of enthusiastic contacts may provide useful usability feedback without representing the wider market. Record how participants were recruited, whether they received personal assistance and whether they match the intended customer profile.
Decide in advance what happens next. Strong usage may justify expanding the cohort. Repeated abandonment may call for a workflow change. Little interest from well-matched prospects may warrant revisiting the problem rather than adding features.
How should the first release reach real users?
A controlled launch usually produces clearer learning than a broad announcement. Recruit people who experience the problem now, explain the product's current boundaries and provide a practical route for reporting issues. Early access should be narrow enough for the team to observe failures and respond.
Test the full journey before inviting that cohort. This includes empty states, failed submissions, confirmation messages and recovery from common mistakes. Basic error monitoring helps distinguish a broken interaction from a lack of interest.
Distribution decisions should follow the workflow. A responsive web application may be sufficient for a service accessed through a shared link. A native mobile app may be justified when device capabilities or the usage context are central. App store submission and release processes then become part of the delivery plan.
After launch, review requests against the original assumption. Several people asking for reminders may indicate a genuine obstacle to repeat use. One request for a complex reporting suite is weaker evidence. Prioritise changes that remove observed barriers, then assess whether behaviour improves.
Frequently asked questions
How many features should an MVP have?
There is no useful fixed feature count. An MVP needs enough functionality to complete one meaningful user journey and measure the intended outcome. A booking service may need availability, booking and confirmation, whereas another product needs a different set. Assess each feature against the assumption being tested, rather than an arbitrary limit.
Should an MVP be free or paid?
Charge when willingness to pay is a central assumption and the product can deliver the promised value. Free access can help test usability or adoption, but it does not establish commercial demand. Record any discounts, personal support or incentives, because those conditions may affect whether early behaviour continues under normal terms.
Can an MVP include manual work behind the scenes?
Yes. Manual matching, data preparation or support can reduce development spending while testing whether users value the outcome. The process must still deliver what users were promised. Track the time and cost involved, and distinguish evidence of customer demand from evidence that the service can operate economically at a larger scale.
When should founders add more features to an MVP?
Add features when observed behaviour identifies a barrier to the core outcome or supports a clear next hypothesis. Repeated user difficulties, lost transactions or unmet needs among the intended audience are stronger signals than isolated suggestions. Check whether a simpler change could solve the problem before expanding the product's scope.
Final considerations
A well-scoped MVP makes the next decision clearer. It connects a narrow audience, a meaningful problem and an observable outcome, while leaving enough budget to act on what the launch reveals.
The discipline lies in preserving a complete core experience without treating every plausible future requirement as a present obligation. Progress should be judged by stronger evidence and better investment decisions, rather than the size of the feature list.