MVP

Why it matters

It lets a business test real demand before committing the cost of a full build. A mockup shows whether people like how something looks; an MVP shows whether they will actually use and pay for it, which is a fundamentally different and more expensive question to answer well. It also changes the nature of the risk being taken: instead of betting a full platform's budget on an unproven idea, an MVP bets a much smaller amount specifically to learn whether the larger bet is worth making at all. It also forces genuine prioritisation: deciding what is truly essential to test the core hypothesis, versus what merely feels necessary, is itself a valuable exercise most teams skip when building the full version straight away.

What goes wrong when it's handled badly

Building too much into an MVP defeats its purpose: if it takes as long and costs as much as a full platform, it has stopped being minimum and started being a slow, expensive way to build the real thing. The opposite failure, a fake clickable mockup presented as an MVP, tests whether people like a design, not whether the underlying idea actually holds up under real use. A concrete example is a team spending months adding a full admin dashboard, granular permissions and reporting to their MVP before a single real customer has used the core product, work that answers no open question about whether the idea itself actually works. Defining the specific question the MVP needs to answer before writing any code, and stopping once that question is answered, is what keeps an MVP from quietly turning into a full build by another name.