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.
The MVP cycle in Lean Startup
- Build the smallest version that answers the chosen question
- Measure what people actually did and where they got stuck
- Learn revise the assumption or the product and go again
Want to test your idea with real users? I design and build the first version in 4 to 8 weeks for a fixed price. MVP development with me starts at €3,200.
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.
What a prototype proves and what an MVP proves
- Prototype
- tests controls, comprehension or response to an offer
- may not establish payment reliability
- nor willingness to keep paying
- MVP
- truthfully tests the chosen assumption
- part of the fulfilment can be manual
- must not mislead participants
Preparing the first version
Five steps to the first version
- One main problem the actual user and the current process
- Journey input, outcome and error state of every step
- Experiment a supervised pilot, a manual service or software
- Data and operations purpose, access, retention, recovery
- Findings and next step numbers and the reasons people did not continue
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 | €60/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.
What an MVP handover should contain
- Repository the project code
- Documentation written for whoever takes the project over
- Access and licences to every service the application uses
- Deployment and recovery procedures that another supplier can follow
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.
What to take away
- An MVP should answer an important question, not deliver the fewest screens at any cost.
- First formulate the question you are testing, and only then choose features.
- Decide in advance what the result proves: interest in a demonstration is not a paid subscription.
- Authorization checks and data protection are not postponed just because it is an MVP.
- MVP development with me starts at €3,200 and takes an indicative 4-8 weeks.
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.