An MVP tests one product assumption through a complete customer journey. A broader platform serves established demand across connected roles and operations.
Choose based on what you need to learn, what customers already expect and what your team can handle manually.
Compare your starting points
| Your situation | Start with a focused MVP | Plan a broader platform |
|---|---|---|
| Demand | The problem or willingness to pay needs testing. | Customers already depend on the service. |
| Scope | One audience and journey can prove the idea. | Several connected roles are essential. |
| Operations | Staff can handle occasional exceptions. | Volume makes manual work impractical. |
| Dependencies | Few integrations are needed to launch. | Contracts or existing systems define launch requirements. |
| Success | Evidence to decide the next investment. | Reliable delivery against understood requirements. |
Choose one complete journey
A booking app might start with one service and staff-assisted scheduling. Customers still need availability, confirmation and a way to resolve problems.
Include the operational work behind the screen. Loyalty programmes and extra locations can wait.
- Name the customer and the task they need to complete.
- Separate launch essentials from later improvements.
- Define the evidence that would justify further investment.
Keep the foundations sound
A small release still needs access controls, error handling, backups and a reliable deployment process.
Build for realistic demand. Document compromises so future development starts with clear decisions.
Decide what happens after launch
Track completed journeys, repeat use and operational effort. Review once you have meaningful usage.
Expand what works, fix what fails or change the proposition. Keep ownership of your code, documentation and system access.
Bring these questions to your brief
- Who must the first release serve?
- What evidence supports demand?
- What can staff handle manually?
- What result would justify expansion?