What an MVP is actually for
A minimum viable product exists to test whether the core problem is real and whether the proposed solution actually solves it, with the least amount of work required to find out. It's not a smaller version of the final product with fewer features — it's a different thing entirely, built to answer one question as cheaply as possible: will people actually use this and pay for it.
What belongs in v1
- The one workflow that proves the core value. Not every workflow the product will eventually need — the single one that, if it works, proves the idea.
- Just enough auth and billing to charge real money. Fake pricing pages don't validate willingness to pay. Real payment collection, even simple, does.
- Enough reliability that early users trust it with real data. An MVP that loses data or breaks constantly won't get honest feedback about the actual idea.
What almost never belongs in v1
- Admin dashboards and internal tooling nobody outside the team will use yet.
- Configurability and settings for edge cases that haven't come up with real users.
- A polished design system built for scale before there's anything to scale.
- Integrations with third-party tools "in case someone asks" — build them when someone actually asks.
Multi-tenancy is not optional, even in an MVP
This is the one place where MVP thinking has to bend. Multi-tenant data isolation — making sure one customer's data is never visible to another — has to be right from the first version, because retrofitting it later usually means a full data migration under pressure, with real customer data at stake. Everything else can be simplified for v1. This can't.
How to know when the MVP has done its job
An MVP is done being an MVP when it's answered its question: either the core workflow gets real, repeated usage and people are willing to pay for it, or it doesn't and the product needs to change direction. The mistake isn't building an MVP that's too small — it's continuing to treat the product as an MVP long after it's proven the idea, using that as an excuse to keep skipping the reliability and structure a real product needs.
The practical takeaway
Build the smallest version that can prove or disprove the core idea, get multi-tenancy and billing right from day one even though everything else is minimal, and resist the pull to add features nobody has asked for yet. The goal of an MVP is to learn something real, as cheaply as possible — not to ship a smaller version of a product you've already decided to build.