~12 min read · You paid for an MVP. Is it a launchpad you can build on, or a prototype that needs to be thrown away? A practical diagnostic for non-technical founders.
Few terms in software get more abused than "MVP."
It's been used to mean a working product. A demo that runs but couldn't survive contact with real users. A landing page with a sign-up form. A six-month engineering project. A weekend hack. A serious foundation for a year-long roadmap. A thing somebody built once and never opened again.
When you paid for "an MVP", you were probably picturing one of these. The person you paid was probably picturing a different one. The result you got is somewhere in between, and now you're trying to figure out what to do with it.
This article is about figuring that out. What an MVP is actually supposed to be. What kinds of MVPs exist in the wild. How to tell which one you bought. And what to do if what you bought isn't what you needed.
The Term Nobody Really Defined
The phrase "minimum viable product" comes from Eric Ries and the Lean Startup movement, and in its original meaning, it had nothing to do with the quality of the code.
An MVP, originally, was an experiment. It was the smallest thing you could build that would teach you something useful about your customers. It might be a working app. It might be a single landing page. It might be a manual process where humans did the work behind the scenes while you pretended it was automated.
The point was learning, not shipping.
That definition is still correct, in its original context. It's just not the definition anyone uses anymore.
In current usage, "MVP" has come to mean something more like: the first version of the product, with enough features to launch and get real users. Which is a fine definition, except that it doesn't say anything about what "enough" means, or how solid the foundation has to be, or whether the code is meant to be built on or thrown away.
Both parties used the same word. Both meant different things.
The Three MVPs
There are, in practice, three different things commonly delivered when someone is paid to build an MVP. They cost different amounts. They serve different purposes. And they need to be treated differently after delivery.
The first is the prototype. It works on the developer's machine, in the demo, on the happy path. It might handle two or three users without breaking. If you tried to put a hundred real users on it, things would start going wrong in ways the developer didn't plan for. The prototype was built to show the idea, not to carry the idea.
The second is the launchpad. It runs in production. It can handle real users — at least a few hundred to a few thousand. It has logging when things go wrong, a way to deploy updates, and the structure underneath is clean enough that the next features can be added without major surgery. The launchpad was built to be grown, even if it's still small.
The third is the production-grade first version. It does everything the launchpad does, plus monitoring, plus alerting, plus structured error handling, plus a real backup strategy. It's the version you'd want if you were planning to put thousands of users on it from day one. It costs noticeably more than the launchpad — usually 50% to 100% more — and most early-stage products don't need it.
These three are not the same thing. A prototype priced like a launchpad is a bad deal. A launchpad priced like a production-grade build is a bad deal. A production-grade build priced like an MVP is the rarest and best deal, and almost never happens.
When you paid for "an MVP", the question is: which of these did you actually receive?
Five Questions to Tell What You Got
You don't need to read the code to figure this out. You need to answer five questions, all of which are observable from your side.
Can it onboard a stranger? If you handed your app to someone who's never seen it — no introduction, no setup help, no developer on call — could they sign up, use it, and get a useful outcome?
If yes, you have at least a launchpad. If no, you have a prototype. The prototype usually works fine for the people who built it and breaks for everyone else.
What happens when you put bad data in? Try the things a real user would do that the developer probably didn't test. Submit a form with weird characters. Enter a phone number from a different country. Upload a file that's slightly too large. Sign up twice with the same email.
If the app fails gracefully — with a clear message and no permanent damage — you have a launchpad. If it shows a blank screen, an error code, or simply does nothing, you have a prototype.
Could someone other than the original developer extend it? Ask a different developer — even just for an hour — to take a quick look. Could they make a small change without breaking other things? Could they figure out how the app is structured?
If yes, you have a launchpad. If they need three days to figure out where anything is, you have a prototype.
Does anyone know when something goes wrong? If a payment fails for a real user right now, somewhere, would anyone find out? Is there logging? Alerts? A way to see what users are doing?
If yes, you have at least a launchpad and possibly a production-grade build. If no, you have a prototype that's been deployed — which is worse than a prototype that's still on the developer's laptop, because real users are now hitting it.
Has anyone outside the build team actually used it? Not "looked at it" — used it. Signed up, used the main features, tried to do real things with it.
If yes, you have at least a launchpad. If no — if the only users so far have been the people who built it — you have a prototype that hasn't been validated as anything else.
These five questions, taken together, give you a quick read on what you actually bought. Three or more "no" answers, and you have a prototype. Three or more "yes," and you have a launchpad. Five "yes," and you might have something closer to production-grade.
The Industry Pricing Reality
Here's what each tier actually costs, with the caveat that local market rates vary widely and these are mid-2026 numbers.
A real prototype — built for demonstration, not for users — usually costs somewhere between $800 and $5,000 depending on complexity. At that price, you should not expect anyone to use it without a developer next to them. You should not deploy it to production. You should treat it as a learning artifact: it taught you what your product could feel like, and now you know whether to build the real thing.
A launchpad — the version real users can use, built with the structure to grow — usually costs between $8,000 and $20,000 for a typical mobile app with a backend. This is the version most early-stage founders actually want and most don't budget for. It is also the version most worth paying for, because it can be built on. A launchpad becomes a year-two app with feature work, not with a rebuild.
A production-grade first version — the launchpad plus monitoring, alerting, error handling, real backup, on-call thinking — usually costs $20,000 to $40,000 and up. Most early-stage products don't need this. The exception is when failure has serious consequences (financial transactions, medical data, anything regulated) — in which case the production-grade version is the actual minimum, regardless of what anyone calls it.
These ranges don't fit neatly into the "MVP" word, which is part of the problem.
A buyer who asks for an "MVP" and has $3,000 to spend is asking for a prototype. A buyer who asks for an "MVP" and has $15,000 to spend is asking for a launchpad. Both are reasonable requests. Neither is well-served by using the same word for them.
When a Prototype Is the Right Answer
Not all prototypes are wrong purchases. There are situations where buying a prototype, knowing it's a prototype, is exactly the right move.
If you're not sure whether your idea is worth building at all, a prototype answers the question cheaply. You spend a few thousand dollars to find out whether the product feels right when it's in your hands, whether users react the way you hoped, whether the workflow you imagined survives contact with reality.
If the answer is yes, you commission a launchpad next, knowing what you actually need. If the answer is no, you saved yourself $15,000 and a year.
This is the original sense of an MVP — a deliberate experiment. The only requirement is that you know going in that you're buying an experiment, and you don't expect the prototype to become the foundation of the real product. The prototype is a teacher. After it has taught you, you build something else.
The mistake isn't buying a prototype. The mistake is buying a prototype thinking you bought a launchpad, and then trying to grow features on top of it for the next year. That doesn't work, because a prototype wasn't built to grow. The wider you stretch it, the more it cracks.
If You Bought a Prototype and Need a Launchpad
This is the most common situation. The buyer wanted a launchpad. They paid launchpad-tier money, or close to it. They received something that demos well but starts failing the moment real users push on it.
Now what?
You have, broadly, three options.
The first is to extend what you have with great care. Keep adding features, but limit them to the kind of small additions that won't expose the underlying fragility. Every new feature is a careful surgery. This is the path of least up-front cost and the path of highest long-term cost.
It works for a while. Eventually the cost-per-feature climbs to the point where you're paying more in maintenance than you would have paid to build something solid in the first place. We describe this pattern in detail in the piece on technical debt.
The second is a partial rebuild. Identify the parts that are the most fragile — usually the data layer and the rules layer (see the three apps inside your app) — and rebuild those while leaving the interface mostly intact. The user-facing experience stays the same. The underneath gets replaced.
The third is a full rebuild. This is the most dramatic option and sometimes the correct one — particularly if the prototype was built so quickly that nothing is salvageable. We cover the decision in you think your mobile app needs a rewrite, including the cases where a rewrite is genuinely the wrong move.
The right path depends on how much of the prototype is recoverable, what the business needs to do next, and how much you can afford. In our experience, the partial rebuild is the most underused option, and the one that fits most situations.
What to Ask Before You Buy the Next One
If you're reading this article because you bought an MVP and now you're not sure what you have — the next time matters more than this time.
A few questions, asked clearly before you sign, will save you from buying the wrong thing again.
Which of the three — prototype, launchpad, production-grade — am I paying for? If the developer hesitates or treats the distinction as artificial, that's worth noticing. A developer who's built more than one of these knows the difference, and is happy to name which one is in scope.
If real users use this on the day it launches, what happens when something goes wrong — and how would I find out? A prototype has no answer. A launchpad has a basic answer. A production-grade build has a thorough one.
Could a different developer pick this up in three months and extend it without rebuilding it? A prototype almost certainly cannot be picked up. A launchpad usually can.
What is explicitly out of scope? A good developer will name things that aren't included — usually monitoring, polished error handling, automated tests, performance under load. A vague answer here is a sign the developer hasn't thought carefully about scope, which usually means you'll end up with a prototype delivered as if it were a launchpad.
We've written more about this kind of reading in how to read a developer's estimate, which goes through what should be in a quote and what's usually missing. The MVP conversation is a specific case of the broader estimate-reading skill.
What You Have, What You Need
The honest summary is that "MVP" as a word has lost most of its meaning, and the best thing you can do as a buyer is to stop using it for a moment and substitute one of the three concrete terms instead.
Did you want a prototype? You should have one that taught you something, then be ready to throw it away.
Did you want a launchpad? You should have one that can carry real users and be grown without major rebuilds.
Did you want a production-grade first version? You should have one that survives the world on its own.
If what you have doesn't match what you needed, the gap is fixable — usually with less surgery than the worst-case version of the situation suggests. The right next step depends on which of the three you have, what your roadmap is, and what kind of partner you have to do the work.
You don't need to be technical to ask the right questions. You just need to know that "MVP" isn't one question. It's at least three. And the difference between the three is the difference between an app that grows with your business and one that becomes a year of patching.