The purpose of a minimum viable product is learning. You want real users solving a real problem with your product as early as possible, so you can find out what they value before spending your budget on everything else.
The challenge is deciding what "minimum" means. Too small and users can't get value from it. Too big and you've spent months building features nobody asked for.
Start with one core job
Write down the single most important problem your product solves, for one specific type of user. Your MVP should let that user complete that job end to end. Everything else is a candidate for later.
What usually belongs in an MVP
- The core workflow that delivers the main value.
- Sign-in and basic account management.
- Billing, if you plan to charge from day one.
- Basic security: secure authentication, data validation and access control.
- Simple analytics so you can see how people actually use it.
- A way for users to give feedback or contact you.
What can usually wait
- Advanced settings and customisation.
- Multiple user roles beyond what launch requires.
- Integrations nobody has asked for yet.
- Native mobile apps, if a responsive web app works for early users.
- Polished admin tools; manual processes are fine at first.
Minimum doesn't mean low quality. Cut scope, not reliability, security or usability.
Validate before you build
Clickable prototypes are one of the cheapest ways to learn. Putting a prototype in front of five to ten target users often reveals confusing flows and missing priorities before any code is written.
Plan for what comes next
A good MVP is built on foundations that can grow: clean architecture, a sensible data model and tests around critical paths. That way, success doesn't force a rewrite.