What should an MVP include?
"Minimum viable product" gets interpreted as everything from a sketch to a full platform. Here is the scoping rule we use with clients: one job done end to end, the basics done properly, and everything else on a list for later.
One job, done end to end
An MVP exists to let real users complete the core job your product promises, and to teach you whether they want it. That means one workflow, complete: a customer can book, pay, and receive confirmation. A dispatcher can create a job, assign it, and close it. Half of two workflows is worth less than all of one, because nobody can actually use it, so nothing gets validated.
The discipline is picking that one workflow. Ask: which single process, moved into software, would make a paying user say this already saves me time? That is the MVP. Everything else is a candidate for version two.
The basics you cannot skip
- Login and accounts, if users see their own data. Simple, but real: password reset included.
- Error handling and validation. The app must fail politely, not silently lose an order.
- An admin view. You need to see and correct what users do without calling a developer.
- Security and backups. Customer data handled properly from day one, not retrofitted.
- Deployment you can update. An MVP is version one of many; shipping week two must be easy.
These rarely appear on feature wishlists, yet they are the difference between a demo and a product. They are also a fixed part of why our MVPs start at EUR 8,900; the full breakdown is in what MVP development costs.
What can safely wait
Multiple user roles beyond the essential ones. Dashboards and analytics before there is data worth analyzing. Integrations with every tool you use, instead of the one that removes manual work today. A native mobile app when a responsive web app reaches every phone already. Notification settings, themes, exports: all real features, none of them needed to learn whether the core job lands. Scope is also the main lever on schedule, as how long a digital project takes shows.
Key takeaways
- An MVP is one core workflow, complete end to end, that a real user can finish without workarounds.
- Production basics are not optional: auth, error handling, an admin view, security, easy updates.
- Minimum refers to scope, never to quality. Quality is what lets the MVP grow instead of being rebuilt.
- Everything cut goes on a version-two list, and real usage reorders that list better than any plan.
Practical advice
Write your feature list, then mark each item: does the core job fail without it? Be strict; most lists shrink by two thirds and nothing of value is lost, only deferred. If deciding what makes the cut feels hard from the inside, that is a scoping conversation more than a technical one, and it is exactly what a discovery call is built for.
Bring the marked-up list to a free discovery call and you will leave with a concrete first-version scope and a number attached to it.