Before building an MVP, ask what business assumption the first release should test. For example: will small studios use a self-service booking tool? That answer determines the features, budget and evidence you need.
1. Define the hypothesis and scope
An MVP is a minimum viable version that allows a team to collect user feedback, as described by Atlassian. A useful brief identifies the audience, their task and an observable outcome. For a booking service, that might be a completed reservation without an administrator's help.
Separate what the experiment needs from what can wait. A customer account may be essential; a loyalty programme may not be. Agree on the condition for continuing before you see the results.
2. Design one complete journey
The first release should let someone finish the main action. Booking requires selecting a service and time, receiving confirmation and finding support. Errors and unavailable slots belong in the same journey.
Use a prototype to test wording and the order of steps before implementation. Ask a potential user to complete the task without coaching. Describe the administrator's work as well: who updates availability, corrects mistakes and receives requests?
3. Build the foundation and test failures
Development includes the interface, server logic and data storage when the chosen journey requires them. Authentication, roles, payments and integrations are included according to need, rather than added automatically.
Give each feature an acceptance condition. Repeated clicks should not create duplicate orders; an offline request should not look successful. Before launch, check permissions, backups, error handling and recovery of the core journey after an interruption.
4. Launch, measure and hand over
Agree on analytics events before release: starting, completing, abandoning and failing the journey. Avoid collecting unnecessary personal data. Review early results alongside user interviews: numbers show where people struggle; conversations help explain why.
Handover includes source files, owner access, instructions, known limitations and support arrangements. Estimate cost from the agreed scope and dependencies. A universal promise to build any MVP in two weeks is no substitute for understanding the task.
What to do next
Start with one audience, one task and one measurable outcome. Agree on release scope, acceptance conditions and how you will make the next decision after launch.