A minimum viable product is not the cheapest version of a finished platform. It is the smallest credible product that can test an important commercial or behavioural assumption with real users.
Define the riskiest assumption
A founder may be uncertain whether customers will pay, whether a workflow is convenient enough or whether an integration can support the service. The first release should generate evidence about the uncertainty that could invalidate the business case.
Choose one complete journey
Users need to complete a useful outcome end to end. A coherent booking, request, assessment or purchase journey is more valuable than many disconnected screens that demonstrate future intentions.
Keep operations deliberately manual
Early back-office work can often be handled manually while the customer-facing proposition is tested. This saves development time and helps the team learn what should eventually be automated.
- Manual review behind a customer form
- Spreadsheet administration for low initial volume
- Direct onboarding before self-service
- Simple reporting before a full dashboard
Budget for learning after launch
Do not allocate the whole budget to version one. Reserve capacity for analytics, user feedback and changes. The first production users will reveal priorities that workshops alone cannot.
Know when the MVP has worked
Agree success and stop criteria before release. Metrics might include completed journeys, repeat use, paid conversion, processing time or qualified interest from a target customer group.