MVP, or minimum viable product, is one of the most used and most misunderstood terms in building software. It is not a cheap, broken version of the real thing. It is the smallest version that actually delivers value and lets you learn whether you are building something people want, before you spend everything building the full vision.
An MVP is the leanest product that solves a real problem for real users well enough that they will use it and give honest feedback. The emphasis is on both words: minimum, so you learn quickly and cheaply, and viable, so it genuinely works for its core purpose. The goal is validated learning, discovering whether the core idea holds, not shipping a feature list.
An MVP is not a prototype nobody uses, and it is not a full product with the corners cut so badly it fails at its one job. The common failure is either building far too much before testing anything, or shipping something so minimal it does not actually deliver value and teaches you nothing. Viable is not optional; a minimum product that does not work is not an MVP, just an unfinished one.
Most product ideas are partly wrong in ways you cannot see from the inside. An MVP surfaces which parts by putting a real, working slice in front of real users early, so you invest the big money in what actually resonates. Building the full vision first, then discovering the market wanted something different, is the expensive mistake the MVP exists to prevent.
Small enough to learn, real enough to use.
This is general educational information about building software, not specific technical or business advice.