I have lost count of how many times a founder has said the word “MVP” to me and meant something completely different from the founder I spoke to the week before. One means “the cheapest thing you can build me”. Another means “the full app, but I will call it an MVP so it sounds lean”. A third means “a prototype I can wave at investors”. The MVP is probably the most misunderstood word in tech, and the confusion is not harmless. It sets budgets, shapes scope, and quietly decides whether a project ships something useful or something embarrassing. As a founder who also builds, I have been on both sides of this misunderstanding, so let me try to untangle it.
What people think an MVP is
The phrase “minimum viable product” was popularised by the lean startup movement, and somewhere along the way the three words got flattened into one idea: cheap. When most founders say MVP, the word doing the work in their head is “minimum”. They picture the smallest possible spend, the shortest possible timeline, and a stripped-back product that does one thing badly but exists.
That reading is not stupid. It is just incomplete, because it only hears one of the three words. “Minimum” is a constraint on scope. “Viable” is a constraint on quality. “Product” is a constraint on usefulness. Drop either of the last two and you no longer have an MVP, you have a demo, or a prototype, or a pile of screens that photograph well and help no one.
What an MVP actually is
A minimum viable product is the smallest thing you can build that a real person will use to solve a real problem, and that teaches you something you did not already know. The emphasis is on “viable” and “learn”, not on “minimum” and “cheap”. It has to work. Someone has to be able to complete the core job end to end, without you standing over their shoulder explaining what the buttons mean.
That definition rules out a lot of what gets called an MVP. A landing page is not an MVP, it is a test. A clickable Figma file is not an MVP, it is a prototype. A version of your app with the payment step disabled is not an MVP if payment is the point. The test of viability is simple: can a stranger get value from this without you? If the answer is no, you have built something earlier in the funnel than an MVP, which is fine, but call it what it is.
Why the misunderstanding costs money
The confusion is expensive in both directions. When a founder means “cheap” and hears an agency say “yes, we do MVPs”, they often end up with something technically minimal but not actually viable. It launches, nobody can use it, and the conclusion drawn is “the idea failed” when what actually failed was the definition. I have watched founders kill perfectly good ideas because their so-called MVP was never viable enough to give a fair signal.
The other direction is just as costly. A founder who quietly means “the whole product” but labels it an MVP ends up scoping a six-figure build under a word that promised twenty-odd thousand. The gap between the word and the work becomes a source of tension for the entire project. If you want the honest version of those numbers, I wrote about how much an MVP actually costs in the UK in 2026, and the short version is that “MVP” and “cheap” are not synonyms.
The word that would serve founders better
If I could delete “MVP” from every founder’s vocabulary and replace it with one question, it would be this: what is the smallest thing that would teach me the most? That question does the work the acronym was supposed to do. It forces you to name the assumption you are most afraid of, and then to build only the thing that tests it.
Sometimes the answer is not code at all. You can validate an enormous amount of demand before you write a line, and I have argued before that the best first move is often to test your idea without building the product. Other times the riskiest assumption genuinely is “can this be built and will it feel good to use”, and then you do need to build something real. The point is that the scope follows the question, not the other way round. You do not start with a budget and work backwards to a feature list. You start with the thing you need to learn.
What we do differently
When a founder comes to us and says MVP, the first thing we do is refuse to accept the word at face value. We ask what they are trying to learn, who the first ten users are, and what “it worked” would concretely look like. Half the time the scope shrinks, because it turns out the thing they were nervous about is smaller than they feared. The other half it grows slightly, because viability demands one more piece than they had budgeted for. Either way, the number at the end is honest, and the thing we build is something a real person can actually use.
That is the whole game. Not minimum for the sake of minimum, not viable in name only, but the smallest genuinely usable product that answers the question keeping you up at night. If you are sitting on an idea and you are not sure what your version of that smallest useful thing is, that is exactly the conversation worth having before anyone quotes you a price. You can start one by sending us a short project brief, and we will help you find the real MVP hiding inside the word.
The next time someone says “it is just an MVP”, ask them which of the three words they mean. You will learn a lot about the project from the answer.
.webp)
.webp)
