A minimum viable product should let a specific user complete one valuable task and give its founders evidence about whether the business idea deserves further investment. This article explains how app founders can define that task, limit development scope and launch a focused product without spending their budget on untested assumptions.
Key takeaways
- Define one initial user group and one valuable outcome before turning the idea into a development brief or feature backlog.
- Test the assumption most likely to undermine the business, rather than building the features that are easiest to describe.
- Keep the core workflow complete, but defer secondary features and use manual operations where they will not distort the test.
- Document exclusions alongside requirements so new requests become explicit budget decisions rather than quiet additions to the first release.
- Agree activation, repeat-use and commercial signals before launch, then assess actual behaviour rather than downloads or positive comments alone.
What is a minimum viable product?
A minimum viable product is the smallest usable version of an app that enables a real user to complete its core workflow and produces evidence about a business hypothesis. Its purpose is to reduce uncertainty before the founder commits to a larger build, not to reproduce a finished product at lower cost.
Smallest does not mean incomplete. A booking app that displays available appointments but cannot confirm a booking has not delivered its central outcome. It may test interest in the concept, but it cannot show whether users will complete the transaction.
The distinction matters when commissioning development. A prototype can test whether people understand a proposed interface. A landing page can test whether an offer attracts enquiries. An operational MVP goes further: people use it to achieve something, allowing the product team to observe friction, demand and repeat behaviour.
These approaches answer different questions. Choosing the least expensive suitable test is sensible; describing every early experiment as a launched product makes the resulting evidence harder to interpret.
How do founders choose what an MVP should test?
Start with the assumption that could make the business fail even if the software works perfectly. That might be willingness to pay, the availability of suitable suppliers, or whether a recurring task is painful enough to change established behaviour.
For a hypothetical scheduling app aimed at independent tutors, the main uncertainty might be whether tutors will move bookings away from messages and spreadsheets. Building advanced reporting would do little to resolve that uncertainty. Enabling a tutor to share availability and receive a confirmed booking would be more useful.
Write a short hypothesis that names the user, the problem and the expected action. For example: independent tutors with recurring scheduling conflicts will offer appointment slots through the app and continue using it for subsequent bookings.
Then establish what would weaken that hypothesis. Users might understand the product yet refuse to invite clients. They might complete a first booking but return to their existing process. Both outcomes deserve attention.
A smaller release is useful only when its boundaries preserve the question being tested. Removing the action that would demonstrate value saves development time but leaves the business assumption unanswered.
Interviews help identify the problem. Observed use tests whether the proposed solution changes behaviour. Where willingness to pay is the uncertainty, compliments and registrations are insufficient substitutes for a credible purchasing decision.
How do you turn a user workflow into a feature scope?
Choose a narrow initial audience, defined by a shared situation rather than a broad demographic. “Small businesses” leaves too many differences unresolved. “Independent tutors managing appointments without administrative support” gives a development team clearer decisions to work with.
Map the journey from the trigger to the completed outcome. Include the steps outside the app: invitations, emails, payment arrangements and any work performed by an operator. Hidden operational steps still affect whether the experience succeeds.
- Describe the event that makes the user need the product.
- List the steps required to reach the intended outcome.
- Identify the information and decisions needed at each step.
- Mark which steps require software and which can initially be handled manually.
- Define what successful completion looks like and how it will be recorded.
Convert that map into requirements with observable acceptance criteria. “Users can manage bookings” is too broad. “A tutor can publish an available slot, receive a booking and see its confirmed status” provides a testable boundary.
Include likely failure paths. A duplicate booking, an invalid submission or a missed confirmation can prevent the core task from working. These are not automatically optional extras simply because they are absent from the ideal journey.
Onboarding belongs in the scope where it is necessary to reach value. Collect only the information needed to complete the first task; lengthy profile setup can obscure whether users actually want the service.
Which features should be left out of the first release?
A feature should earn its place by supporting the core outcome, making the product usable in its intended setting, or generating evidence for the chosen hypothesis. Familiarity is not a sufficient reason. Many established apps have dashboards, referral schemes and extensive preferences because their businesses are already operating at a different stage.
Keep a written out-of-scope list beside the build specification. For a booking product, this might include multi-location administration, custom reports, loyalty features and complex calendar rules. Each exclusion should have a reason and, where useful, a condition for reconsideration.
Use manual work without weakening the test
Manual account setup, supplier approval or a basic email notification can replace early automation. This is appropriate when users can still experience the promised outcome and the operating team can deliver it consistently.
Record the time and effort involved. A service that requires substantial intervention may demonstrate demand without demonstrating a viable operating model. That distinction should remain visible in the launch review.
Do not defer essential access controls, appropriate handling of user information or transaction correctness merely to reduce scope. The relevant requirements depend on the product and the data it handles. If those obligations exceed the available budget, narrow the use case rather than releasing a careless version.
A later-version backlog gives deferred ideas a home. It should remain provisional: evidence from the first release may make some of those features unnecessary.
How can founders control MVP development costs?
Budget control starts with decisions, not hourly rates. An ambiguous requirement can create design revisions, new data structures and repeated testing, even when the original feature sounds modest. Resolve uncertainties about the core workflow before asking a team to estimate the build.
A useful development brief includes the target user, hypothesis, workflow, acceptance criteria, exclusions and measurement plan. It should also identify dependencies such as payment processing, external data or app store submission. These can introduce work that is easy to miss in a screen-by-screen estimate.
Choose the delivery format around the test. A web application may be sufficient if users can complete the task in a browser. A mobile app may be justified when device capabilities or the usage context are central. Native distribution brings submission and release-management work that should be planned rather than assumed away.
No-code platforms and custom code offer different trade-offs in flexibility, maintenance and integration. Neither removes the need to limit scope. Faster implementation can simply produce more unvalidated features.
Agree a change process: describe each proposed addition, estimate its effect and decide whether to swap it for existing work, postpone it or increase the budget. Protect funds for testing, launch support and changes prompted by early use. Spending the entire allocation before anyone uses the product leaves little room to respond.
How should an MVP launch be measured?
Define success before recruitment begins. The primary measure should reflect the promised outcome, such as a completed booking or a submitted request that receives a useful response. Account creation alone rarely demonstrates value.
Track the path to that outcome so failures can be located. If users abandon setup, the issue may be onboarding. If they complete setup but never take the main action, the offer, timing or perceived value may be wrong.
Repeat use needs an appropriate observation window. A weekly scheduling tool and a service used during an occasional house move should not share the same retention expectations. Measure return behaviour against the natural frequency of the problem.
Recruit people who match the intended audience and have a current reason to use the app. Support them, but distinguish unprompted actions from actions completed after repeated reminders.
Review product behaviour alongside conversations, willingness to pay and operational effort. A small early cohort provides directional evidence, not certainty. The next decision should be explicit: continue the current test, change the proposition, fix a specific obstacle or stop further investment.
Frequently asked questions
How many features should an MVP have?
There is no useful fixed feature count. An MVP needs enough functionality for one defined user group to complete the core task, including necessary failure handling. Assess each feature against that workflow and the hypothesis being tested. A short list of broad features can still conceal a large and expensive build.
Can an MVP include manual processes?
Yes. Manual processes can support tasks such as account setup, supplier checks or customer notifications when automation is not needed to test the idea. Record the work involved and avoid presenting a labour-intensive service as proof of scalable economics. The user must still receive the intended outcome reliably.
Should an MVP be a mobile app or a website?
The choice depends on the task and usage context. A web application is often sufficient when the workflow works well in a browser. A mobile app may be appropriate when device capabilities or frequent mobile use are central to the test. Include distribution, release management and maintenance in the decision.
How do you know if an MVP is successful?
Success means the release produces credible evidence against the hypothesis defined before launch. Look for completed core actions, repeat use where relevant, commercial commitment and manageable operating effort. Registrations or favourable comments alone are weak evidence. A result that disproves the idea can still prevent a much larger, unnecessary investment.
Final considerations
A disciplined first release preserves the user's outcome and removes work that does not help test the business. Its boundaries should be clear enough for a development team to estimate, build and assess without continually reopening the product brief.
The aim is not the smallest possible feature list. It is the smallest credible test of demand and delivery, with enough budget remaining to act on what real users reveal.