MVP stands for minimum viable product. The aim is not to deliver the fewest screens at any cost, but to obtain useful evidence about an important question: do people need the solution, understand it and want to use or pay for it?
Lean Startup methodology connects an MVP with the build-measure-learn cycle. Feature count and project duration alone do not determine whether it serves that purpose. The booking example below is not a mandatory feature list for every MVP.
Start with the question, then choose features
"Build a booking system" describes a product, not a testable assumption. A more precise question could be: can a customer find a suitable time and independently book a place previously arranged by reception?
Describe the task, choose participants and decide what to observe in advance. Record reasons for non-completion too. Registration count alone does not explain whether the service helped anyone.
| Decision | Fictional booking example |
|---|---|
| Question | Can a customer book without reception? |
| Essential journey | Time, party size, confirmation |
| Observation | Completion and points of confusion |
| Deferred feature | Loyalty programme |
| Next decision | Revise the flow, continue or test another need |
Sign-in, administration or payments belong in the first version when required by the process and safe operation. Necessary authorization checks must not be postponed simply because this is an MVP.
MVP and prototype are not fixed technical categories
A prototype can test controls, comprehension or response to an offer. It may not establish payment reliability or willingness to keep paying. An MVP can include manual fulfilment where this still truthfully tests the chosen assumption without misleading participants.
State what the result establishes. Five people completing a guided task do not prove market-wide demand. Interest in a demonstration is not a paid subscription. Decide which evidence the next investment requires before starting.
Preparing the first version
1. Choose one main problem. Describe the actual user and current process. Separate observed facts from assumptions.
2. Draw the journey. Define the input, outcome and error state at each step. A wireframe can reveal missing decisions before coding; approving it does not replace a user test.
3. Choose the experiment. A supervised pilot or manually provided service may be enough; another case may require working software. Do not order sign-in and a dashboard simply because another app had them.
4. Address data and operations. When storing personal data, establish purpose, access and retention. For actual bookings, test concurrency, cancellation and recovery. Separate test data from live records.
5. Record findings and the next step. Alongside numbers, record what participants needed explained and why they declined to continue. Use the evidence to revise the assumption or product.
Worked example: MVP: book a workshop place
ORIGINAL EXAMPLE · FICTIONAL DATA
| Element | Concrete brief |
|---|---|
| Screen | Date / party size / confirm |
| Participant task | Book Saturday's workshop for two people. |
| Observation | Can they find capacity and confirm? |
| Metric | Completed bookings / started bookings |
A test plan; no result has been measured.
What MVP development costs
This is my development offer, not a market average or the price of every experiment. Rules, roles, integrations, data, technology and verification affect the budget.
| Scope | My price | Clarify first |
|---|---|---|
| Agreed-scope MVP | from €3,200 | main process and acceptance conditions |
| Ongoing development | €40/h | priorities, budget limit and change approval |
| Production application | from €7,200 | operations, integrations and support |
See MVP for startups for MVP and hourly work, and application development for the production option. A low price alone does not establish a saving; compare equivalent commitments including handover and operation.
How long it takes and who builds it
My MVP offer has an indicative 4-8 week timeline with agreed scope and available materials. The actual schedule must include dependencies and review. Taking over three months does not itself disqualify an MVP, for example when testing seasonal usage or a complex integration.
One experienced person may handle a smaller scope. Demanding data, security or regulated processes may require additional expertise or independent review from the start. Team size is not a measure of cost efficiency.
Technology alone does not guarantee easy handover. Include the repository, documentation, access, licences, deployment and recovery procedures. Verify that another supplier can use them.
Worked example: What belongs in the first test
ORIGINAL EXAMPLE · FICTIONAL DATA
| Requirement | Now | Later |
|---|---|---|
| Booking | Select and confirm | Recurring bookings |
| User account | Access only own bookings | Loyalty programme |
| Administration | Cancel a booking | Advanced reports |
| Data | Backup and restore check | Automated report export |
A smaller scope does not postpone basic security.
Commonly overlooked decisions
- Adding features unrelated to the question being tested.
- Treating a positive comment as actual use or payment.
- Leaving pilot data and support without an owner.
- Defining evaluation only after spending the budget.
- Handing over without access and a verified recovery procedure.
Frequently asked questions
Does an MVP need sign-in?
No. Accounts depend on functionality and data protection, not the MVP label. Private records still need appropriate authorization.
Is an MVP always the cheapest route?
Not automatically. Interviews, a prototype or trying an existing service may help before development. Choose the smallest appropriate step that addresses the actual uncertainty.
What does MVP mean in sport?
It means most valuable player. Only the acronym is shared with product development.
For a concrete process, describe it together with the question you want to test. The application development pricing guide explains budgeting in more detail.