A minimum viable product should prove a specific business assumption through the smallest complete user journey, rather than reproduce every feature in a founder’s plan. For founders preparing an app launch, this article explains how to define that journey, decide what can wait and set evidence-based limits on development spending.
Key takeaways
- Start with the business assumption that could invalidate the idea, then build only what is needed to test it.
- Choose one target user and one complete workflow, including the operational steps required to deliver the promised outcome.
- Keep essential quality standards, but postpone features that do not affect the first meaningful test of user demand.
- Agree scope, exclusions and change rules before development begins so new ideas do not quietly expand the budget.
- Define a measurable success signal before launch, then use observed behaviour to decide whether to improve, change direction or stop.
What is a minimum viable product?
A minimum viable product is the smallest functional version of an app that lets real users complete its core promised action. Its purpose is to test a specific market or business assumption before committing to a broader product.
The word ‘viable’ matters. A booking app that displays available appointments but cannot confirm a reservation does not complete its central promise. Equally, viability does not require loyalty points, calendar integrations or several payment methods if none is necessary for the initial test.
An MVP is therefore a learning tool with a working outcome, rather than a reduced version of an imagined final product. Its scope depends on what needs proving. Demand, willingness to pay, practical delivery and repeat usage are different assumptions, and each requires different evidence.
Which business assumption should the MVP test?
Founders often begin with a feature list because features are easy to describe. A more useful starting point is the reason the business might fail. Users may not experience the problem frequently enough, may resist paying for a solution, or may find the proposed workflow harder than their existing workaround.
The first task is to identify which uncertainty deserves the earliest test. Interviews can establish how people currently handle a problem, but positive comments are not proof that they will adopt an app. Stronger evidence usually involves a commitment: providing real information, completing a task, returning voluntarily or paying for a pilot.
A hypothetical scheduling service for independent tutors illustrates the distinction. If the main uncertainty is whether tutors will pay to reduce scheduling administration, building student profiles and teaching-resource libraries adds little evidence. A working booking journey and an explicit paid offer address the assumption more directly.
- Describe a specific user group and the situation in which the problem occurs.
- Record the current workaround, including its inconvenience or cost.
- State the assumption that must hold for the business to work.
- Choose an observable behaviour that would support or weaken that assumption.
- Design the smallest test capable of producing that evidence.
This process may reveal that software is premature. A manually delivered service or concierge pilot can test demand before a custom build. Any manual intervention should be transparent where it affects what customers believe they are buying.
How do founders choose the right MVP features?
Scope should follow a complete workflow, not a collection of screens. For a simple booking product, that workflow might involve finding an available slot, providing contact details, receiving confirmation and allowing the operator to fulfil the booking. Each step exists because the outcome depends on it.
Mapping the journey also exposes less visible work. Someone needs to manage availability, resolve failed bookings and answer support requests. These tasks may require a basic internal tool, or they may be handled manually during a limited pilot. Neither option should be left undecided.
Separate essential work from later improvements
A useful scope document places proposed features into three groups:
- Required for the test: functionality without which the user cannot complete the core action or the business cannot assess the result.
- Required for responsible operation: appropriate access controls, clear error handling, necessary payment safeguards and a workable support process.
- Deferred: improvements such as advanced reporting, referrals, extensive customisation or integrations that do not change the initial test.
‘Deferred’ is more precise than ‘nice to have’. It makes clear that a useful feature can still be wrong for this release. A written exclusion list helps prevent familiar competitor features from slipping into scope simply because they appear standard.
The strongest early product is often the one that removes uncertainty with the fewest moving parts, rather than the one that demonstrates the most development work.
For each included feature, record a simple acceptance condition. ‘Users can cancel a booking and the operator sees the updated status’ is testable. ‘Flexible booking management’ leaves too much room for interpretation.
What can be manual, and what needs to work properly?
Manual operations can preserve cash when they substitute for low-volume internal work. Matching customers with suppliers, preparing a report or approving a new account may initially happen outside the app. The user-facing promise must still be delivered reliably enough for the test to mean something.
The trade-off is operational capacity. If every completed order requires substantial founder involvement, the pilot should record that effort alongside revenue and usage. Otherwise, apparent demand may disguise a service that is too expensive to deliver.
Quality should be selective, not careless. The central workflow needs understandable labels, useful feedback when something fails and testing on the devices the pilot audience actually uses. An app that loses submitted information or leaves payment status unclear tests user patience rather than the business idea.
Some shortcuts create disproportionate risk. Where an app handles sensitive information, financial transactions or regulated activities, specialist advice and suitable controls may change the minimum acceptable scope. A limited release does not remove those responsibilities.
Platform choice should follow the user’s context. A web application may be sufficient for an early business workflow. A mobile app may be justified where device capabilities or usage habits are central to the proposition. Choosing mobile distribution also introduces store submission work, which belongs in the launch plan rather than appearing as a late surprise.
How can an MVP budget stay under control?
A development budget becomes more useful once it is attached to an agreed test and a defined release. Estimates based on a broad idea leave too many decisions unresolved. Before implementation, founders and the product team should agree the user journey, acceptance conditions, integrations, operational responsibilities and explicit exclusions.
The budget should cover more than coding. Design, testing, deployment, analytics setup, early support and post-launch fixes all consume time. Third-party services also create ongoing costs, even when the initial build is small.
Unknown integrations deserve particular attention. Connecting to an external booking system or importing inconsistent customer records can require more work than the visible interface. A short technical investigation may be a better first purchase than committing to the entire build on an untested assumption.
Use a change rule rather than relying on restraint
New ideas will arrive during development. Each proposed addition should state which assumption it helps test, its likely cost and what it replaces. If it replaces nothing, it changes the budget or release date and requires an explicit decision.
A fixed delivery date alone does not control scope. Without an agreed rule, teams may attempt to fit more work into the same period by reducing testing or leaving workflows unfinished. Preserve a complete core journey instead.
Maintain a separate backlog for later ideas and review it after launch evidence arrives. This gives potentially useful suggestions a place without treating them as immediate instructions. It also makes the difference between the first release and the longer-term ambition visible.
How should an MVP launch be measured?
Success criteria should be written before launch, when decisions are less vulnerable to selective interpretation. Downloads, registrations and page visits can describe reach, but they do not necessarily show that the product solves a problem.
Choose a primary signal tied to the assumption. For a workflow tool, that might be successful completion of a real task followed by repeat use. For a paid service, it might be acceptance of a priced pilot and continued use after the initial delivery.
Track the steps around that signal as well. Where do users abandon onboarding? Do they understand the next action? How many need personal assistance to finish? These observations help distinguish weak demand from a confusing interface or an operational failure.
The observation period should match the problem’s natural frequency. Daily usage is an unsuitable standard for an app designed for an occasional appointment. Repeat behaviour only becomes meaningful once users have had a reasonable opportunity to need the service again.
Launch to a deliberately chosen group whose circumstances match the target market. Record how participants were recruited and how much assistance they received. Friendly testers can provide useful usability feedback, but their willingness to persist may differ from that of ordinary customers.
Agree what follows each result: improve a difficult step, revise the proposition, run another focused test or stop. The purpose of measurement is to guide investment, not to decorate a launch report.
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 core user journey and test a defined assumption. Include the operational and quality requirements that make that journey credible. Defer features that serve other audiences, add convenience or broaden the product without improving the initial test.
Can an MVP use manual processes?
Yes. Manual fulfilment, account approval or report preparation can replace early automation when volumes are manageable. The promised outcome still needs to be delivered, and relevant manual intervention should be explained honestly. Record the time and cost involved so evidence of demand is not mistaken for evidence that the business can scale economically.
How long should it take to build an MVP?
There is no reliable duration without a defined scope. Delivery depends on the core workflow, integrations, platform requirements and quality expectations. Founders should request an estimate against agreed acceptance conditions, including testing and launch work. When uncertainty is high, a smaller discovery or technical investigation is preferable to treating an early estimate as a commitment.
How do you know if an MVP is successful?
An MVP succeeds when it produces credible evidence about the assumption it was built to test. That may involve paid adoption, completed workflows or repeat usage at the problem’s natural frequency. Compare behaviour with criteria agreed before launch, and account for recruitment bias, manual support and operating costs before deciding to invest further.
Final considerations
A disciplined first release keeps the business question visible throughout development. Scope, quality and spending should serve that question, rather than an ambition to look complete beside established competitors.
The next investment should follow observed behaviour. A narrow product that produces clear evidence gives founders a firmer basis for expansion than a broader release whose results are difficult to interpret.