What is an MVP in software development?

An MVP is a minimum viable product: the smallest version of a product that still delivers real value to a real user and lets you learn whether the idea works before you spend the full budget building it out. That’s the definition. What does MVP mean in practice is a harder question, because the way most teams read those three words is the reason so many MVPs fail to teach anyone anything.

Where the term came from

The phrase was coined by Frank Robinson around 2001, and it entered the industry’s bloodstream when Eric Ries built the Lean Startup method around it and published The Lean Startup in 2011. Both meant something specific by it. The point of a minimum viable product was never to ship a cheap, half-finished version of the plan. It was to run the fastest honest experiment that answers one question: will people actually use and pay for this?

Ries framed the MVP as the version of a product that lets a team collect the maximum amount of validated learning about customers with the least effort. The operative word is learning, not launching. That distinction gets lost the moment “minimum” and “viable” start pulling in opposite directions.

The two words that fight each other

Read “minimum” on its own and you get a spec that’s too thin to prove anything. It technically runs, but it doesn’t do enough for anyone to form an opinion, so the feedback you get is noise. Read “viable” on its own and you get a first release that quietly grows into the whole roadmap, and now you’ve spent the full budget to learn what a much smaller build could have told you in weeks.

The version that works holds both words at once. Minimum in scope, so you cut every feature that isn’t load-bearing for the core hypothesis. Viable in quality, so the one thing it does, it does well enough that a user’s reaction is real signal. A payments flow that loses money isn’t minimum, it’s broken. A beautiful settings page on a product nobody has agreed to use isn’t viable, it’s premature.

The failure mode we see most

The single most common way an MVP goes wrong has nothing to do with features. It’s building it on foundations you have to throw away. Teams treat “MVP” as license to ship a prototype, meaning something with no tests, no deployment story, and data structures glued together to demo well. Then the idea works, real users arrive, and the same team is now rebuilding from scratch under load, having learned the thing but kept none of the work.

That’s the trap worth naming plainly: a prototype is disposable by design, and an MVP shouldn’t be. The distinction isn’t polish, it’s whether the thing you built to test the idea is also the thing you keep building on. You can scope ruthlessly and still write code you own, deploy properly, and can extend. Small and real beats large and fake, and both beat small and fake.

Our MVP development work is built around exactly that line. We ship a first version that’s deliberately small but real underneath, deployed and tested, on code you keep, so validating the idea and building the product are the same motion instead of two rounds of spend. The clearest proof we point to is ROSHI, a fintech loan marketplace that grew into one of Singapore’s top three loan comparison marketplaces on a build that started narrow and grew, rather than a demo that had to be rebuilt once it mattered.

So when someone asks what an MVP is, the useful answer isn’t the acronym. It’s a question back: what’s the one thing you need to learn, and what’s the smallest real product that will teach you, without leaving you with nothing to keep? Answer that and the scope writes itself.