The phrase minimum viable product has been used loosely enough that it now means whatever the person saying it wants it to mean. To a founder under time pressure it means the cheapest version. To an engineer it often means the version without the difficult parts. Both readings produce something that answers no question, which is the only thing an MVP is actually for.
The useful definition is narrower: an MVP is the smallest thing you can build that tells you whether the central assumption of your business is true. That assumption is usually about behaviour - will this type of person do this specific thing, repeatedly, and will they pay for it. Everything in the build either helps answer that or it does not belong. Written that way, the scoping argument stops being about features and starts being about what you are trying to learn, which is a much easier argument to settle.
What routinely gets included and should not: an admin panel, when you can administer fifty users from a database client. Multiple user roles, when one role tests the assumption. Settings screens. Onboarding flows for a product nobody has yet agreed is worth using. Elaborate design systems. A native mobile app when a mobile web page would answer the same question in a fifth of the time. Each of these is defensible in isolation and collectively they are how a six-week build becomes a five-month one.
What routinely gets cut and should not: authentication done properly, because retrofitting identity is genuinely painful and a security incident in an early product is disproportionately damaging. Basic analytics, because an MVP that does not tell you what users did has failed at its only job. Payment collection, if the assumption you are testing involves willingness to pay - free usage proves considerably less than most founders hope. And data structures you can migrate later, because throwaway code is fine but a throwaway data model is expensive.
There is a useful test for any feature under debate: if this were missing, would the experiment still tell us what we need to know? If yes, it goes in version two. Most teams find, applying this honestly, that about a third of their planned scope disappears - and that the third they cut was mostly the part they were building because a competitor had it, not because their own question required it.
One thing worth saying plainly, because it cuts against how MVPs are usually discussed: minimum does not mean shoddy. The parts you do build should work properly, because you are asking real people to form a real opinion. An experiment that fails because the product was broken tells you nothing about your assumption - you have spent the budget and learned only that bugs put people off, which you knew. Small and solid beats large and fragile every time.
Finally, decide before you build what result would make you stop. An MVP with no failure condition is not an experiment, it is version one of a product you have already committed to - and teams that skip this step tend to interpret ambiguous results generously and keep going regardless. Writing the number down in advance is the difference between learning something and confirming what you hoped.
