The word minimum has done a lot of damage. It gets read as cheap, or fast, or small, and so an MVP becomes a shrunken version of the eventual product: the same twelve features, each half-built. That is not a minimum viable product. That is an incomplete product, and it will not tell you anything.
An MVP is an instrument. It exists to answer the single question that, if answered wrongly, makes everything else irrelevant.
Name the question first
Before any scope discussion, the question has to be written down in a sentence. Some real examples of the shape it takes:
- Will clinic receptionists actually use this instead of the phone?
- Will a business pay for this at ₹X per month, or only at ₹X/5?
- Can we extract this data accurately enough that a human does not have to check every result?
- Will users complete a five-step onboarding, or do we need to remove three of them?
Notice that each of these implies a completely different build. The pricing question needs a payment flow and almost no product depth. The extraction-accuracy question needs the pipeline and almost no interface. Build the wrong half and you will finish the project without learning anything.
What still has to be real
Scope reduction has limits. Certain things cannot be faked, because faking them changes the answer you get:
- Authentication and data separation, if real users will enter real data.
- Reliability during the evaluation window. Downtime reads as product rejection.
- Analytics. An MVP with no instrumentation produces anecdotes, not evidence.
- The core loop, end to end. Half a loop tests nothing.
Cut features, not foundations. Features are cheap to add later. Foundations are what force the rewrite.
The rewrite trap
The standard argument is that an MVP should be disposable — build it fast, throw it away, build the real one properly. In practice, almost nobody throws it away. It gets traction, the roadmap fills up, and the disposable code becomes the production system with customers on it.
So the useful discipline is narrower than it sounds: be aggressive about scope, and conservative about structure. A typed codebase, a sane data model, migrations, a deployment pipeline and error tracking cost days at the start. Retrofitting them onto a live product with customers costs months.
Knowing when it worked
An MVP has succeeded when you can answer the question you wrote down, with evidence, and make a decision you were not able to make before. That includes deciding to stop. An MVP that produces a confident no in eight weeks has done its job better than one that produces an ambiguous maybe in eight months.