When launching a product, it is easy to spend the budget on features nobody will use. Each one seems useful: a user account, a referral program, recommendations, chat, and multiple payment methods. Together, however, they extend development time while leaving the main question unanswered: do people actually need the product?
An MVP (Minimum Viable Product) is the smallest viable version of a product. Its purpose is not to replicate a large service on a smaller budget, but to test a specific assumption with real users. To do that, the first version must deliver clear value and make the outcome measurable.
Let us look at how to choose features for launch, what can wait, and why cutting corners on reliability does not help validate an idea.
1. Start with a hypothesis, not a feature list
“We want to build a platform for booking appointments with service providers” describes a product, but it is not yet a hypothesis. It does not explain who needs the platform or why someone would choose it over a phone call, a messaging app, or a service they already use.
A more specific assumption is that small studios struggle to manage bookings through messages, while their clients find it easier to choose an available time themselves. The first version should test both sides: whether studios are willing to keep their schedules up to date and whether clients actually book through the service.
Before development, answer four questions:
- Who is your first user? Not “everyone who needs services,” but a specific group with a similar need.
- How do they handle this task today? What exactly is inconvenient about their current approach?
- What value should the first version deliver? For example, the ability to book without waiting for an administrator to reply.
- What outcome would justify continuing? Actual bookings, repeat usage, or a studio's willingness to pay for the service.
Interviews, a prototype, and a manually operated pilot can help test some assumptions before full development begins. If a form and an operator can handle the task initially, you do not necessarily need to build a platform right away.
2. One complete user journey instead of ten sections
Being minimal is about the number of problems the product sets out to solve, not the number of screens. Users should be able to complete the core journey from start to finish, rather than hit a placeholder after a polished sign-up flow.
For a booking service, that journey is straightforward: choose a service, view available times, provide contact details, and receive confirmation. On the studio's side, the booking must appear in the schedule, and the reserved time must no longer be offered to another client.
If this journey works, the product is ready to be tested. If the catalog, profile, rewards, and news sections are ready instead, but bookings still have to be completed through messages, the team is not yet testing the promised value of self-service booking.
You can limit the first version to one service category, a few studios, or a single city. This reduces development and support work without breaking the core user journey.
3. What to include in the first version
There is no universal feature list for an MVP. The scope depends on the hypothesis, the risks, and what is needed to deliver the outcome. In our example, the boundary could look like this:
| Feature | Decision for the first version | Reason |
|---|---|---|
| Service and available time selection | Include | This is the product's core value |
| Contact details and booking confirmation | Include | Both the client and the studio need to know the booking is confirmed |
| Schedule management | Build a minimal version | Without up-to-date time slots, you cannot test self-service booking |
| Full-featured user account | Postpone if a booking link is enough | Sign-up should not be mandatory unless it is necessary |
| Online payment | Include if testing advance payment | Paying on site may be enough to test booking |
| Recommendations and a rewards program | Postpone | They are not needed for the first booking |
It is important to distinguish between payments within the product and testing willingness to pay. If the business model involves subscriptions for studios, you can start by issuing invoices manually. However, a free pilot alone does not prove that studios will later purchase a subscription.
Analytics should also be included from the start, but without a complex reporting dashboard. Track the key steps: viewing available times, starting a booking, confirmation, cancellation, and an actual visit. The last outcome may need to be recorded by the studio.
4. What can wait or be handled manually
The first version often does not need complex personalization, a multi-tier referral system, gamification, dozens of integrations, or separate apps for every platform. The exception is when that particular capability is what you are testing.
For example, if the idea is based on matching users with service providers through personalized recommendations, removing the matching feature and leaving a standard catalog means testing a different product.
Some internal processes can temporarily remain manual:
- Onboard the first studios and help them set up their schedules.
- Handle inquiries through an existing support channel.
- Prepare reports from exported data instead of building a separate dashboard.
- Review disputed transactions using a predefined procedure.
For each manual operation, define an owner, a manageable workload, and the point at which it should be automated. Otherwise, initial savings will turn into unnoticed ongoing costs.
Manual work must not conceal a broken core journey. If clients are promised instant booking but an operator spends hours arranging a time, the pilot's results will be distorted.
5. Where you should not cut corners
An MVP can be small, but it must not lose data, charge users twice, or expose someone else's information. These failures make it harder to validate demand: users are rejecting a faulty service, not the idea itself.
The minimum safeguards depend on the product. Typically, you need access controls, secure storage of secrets, input validation, backups with tested recovery, and monitoring of critical errors.
If payments are involved, you need to handle duplicate provider notifications correctly, distinguish successful payments from incomplete ones, and support refunds. A booking service must also prevent two clients from booking the same slot at the same time.
The higher the risks, the larger the mandatory scope of the first version. Handling personal data, finances, or regulated services may require additional legal and technical reviews. Calling the product an MVP does not remove these requirements.
At the same time, you do not need to build infrastructure for millions of users in advance. The architecture should suit the pilot's expected load, have clear limits, and allow a validated product to grow without unnecessary complexity at the start.
6. The budget must cover more than development
If you spend everything on the first release, there will be no money left to attract users or fix problems. A working product without an audience will not provide the data you need to make a decision.
Account for these costs separately:
- Developing the hypothesis, user journey, and prototype.
- Building and testing the first version.
- Recruiting and onboarding pilot participants.
- Infrastructure, external services, and support.
- A reserve for changes based on initial observations.
There is no universal budget allocation in percentages. Integrations may be the biggest expense for one product, while customer acquisition may dominate another. What matters more is understanding the cost of each stage and deciding in advance how much the team is willing to spend before the next decision.
Before launch, agree on the testing period, target audience, and success criteria. For a booking service, these might include completed bookings, the share of appointments actually attended, repeat bookings, and studios' willingness to pay. Set thresholds for your specific model rather than borrowing them from someone else's case study.
Sign-ups alone are not enough. You need data on whether people receive value and at what cost. If bookings only happen after expensive advertising or ongoing help from an operator, those costs must be included. A small pilot points you toward the next test, but it does not yet prove that the economics will remain sustainable at scale.
Checklist: does this feature belong in the MVP?
Before adding each feature, ask:
- Which hypothesis does it help test?
- Can users complete the core journey without it?
- Is it needed for security, mandatory requirements, or correct operation?
- Can an existing tool or a manual operation temporarily replace it?
- What will both development and ongoing maintenance cost?
- What data will show that the feature is genuinely useful?
If a feature does not help test the hypothesis, address a risk that must be covered, or deliver the outcome, it should be moved to a later version.
A good MVP does not promise everything at once. It solves one clear problem, helps you observe real user behavior, and leaves a budget for the next step. After the pilot, that step may be developing the product further, changing the user journey, or abandoning the idea. Each of these outcomes is more useful than an expensive launch without an understanding of demand.