The purpose of an MVP is validated learning. The question is never "what can we build in eight weeks" but "what must be true for this business to work, and what is the cheapest way to find out". Sometimes the answer is software; sometimes it is a concierge service where a human performs what the product would eventually automate, which tests demand without building the automation.
Scoping follows the riskiest assumption. If the risk is whether anyone wants the outcome, the MVP delivers the outcome by whatever means. If the risk is whether users can operate the product, the MVP is the workflow with a mocked backend. Features that do not bear on the assumption under test are not deferred — they are excluded, because they cost time and teach nothing.
The two failure modes are symmetrical. Too big: six months of polish on a product whose premise is untested, which is not an MVP but a small launch with no evidence behind it. Too small: a landing page that measures only whether people click, which tests appetite in the abstract rather than the actual solution. After the test comes the decision — iterate, pivot or stop — and an MVP that does not force that decision was theatre. Engineering inside an MVP optimises for change speed, while avoiding the few choices that are expensive to reverse: the core data model and the identity system.
A scoping example makes the idea concrete. A team testing demand for a meal-planning service does not need recommendations, payments and delivery integrations; it needs to learn whether people will plan meals from its suggestions. A weekly email assembled semi-manually for fifty subscribers tests exactly that, in a fortnight, and the answer decides what — if anything — gets built. The software is the last step of the experiment, not the first, and every week spent building before the assumption is tested is a week of evidence-free risk.
"Viable" is the word teams under-weight. An MVP must be good enough that feedback is about the concept rather than the bugs — one polished core flow beats ten rough ones, because users judge the promise through the single path that works. The craft lies in finding that path: the one journey a user would return for, built to a standard that makes the test fair. Anything beyond it is not scope discipline, it is insurance purchased with time the experiment does not have.
Codazz builds this in production — SaaS Development.