MVP – Prototype, Product, or Production?
“MVP” is one of the most commonly used terms in product development. It is also one of the least consistently understood. Ask a founder, a product manager and a software agency what an MVP is, and you will often get three different answers. The problem is not the definition itself. The problem is that those different interpretations lead to very different expectations around cost, timelines and outcomes.
That is where projects begin to drift. In this article, we break down the three most common meanings of MVP and explain why aligning on this early matters more than most teams realise.
The Problem with “MVP”
At a high level, MVP stands for Minimum Viable Product. The intention is clear. Build the smallest thing that delivers value and allows you to learn, but in practice, the term has become overloaded.
Some teams use it to describe something they can demo. Others use it to describe something they can sell. Others still use it to describe something they can scale. These are not the same things! When teams use the same word to describe different outcomes, misalignment is almost guaranteed.
1. The Prototype
For some teams, an MVP is effectively a prototype. This is something that:
- Demonstrates an idea
- Can be shown to stakeholders or investors
- May include limited or mocked functionality
- Is not intended for real users at scale
The focus here is speed and clarity of concept. It might be built using rapid tools, AI-assisted code or even partially mocked interfaces. Shortcuts are acceptable because the goal is learning and communication, not long-term maintainability.
This is often the right approach in the early stages of a product. The risk appears when a prototype is mistaken for something that can be used in production.
2. The MVP (In the Lean Sense)
In the original Lean Startup sense, an MVP is a product that:
- Delivers a real piece of value
- Can be used by real users
- Allows the team to learn from actual behaviour
- Is intentionally limited in scope
However, even at this stage, the product still needs:
- Basic security
- Reliable data handling
- A coherent user experience
- Enough structure to support iteration
This is closer to what many teams aim for. It is not a throwaway build. But the challenge is that this version of an MVP sits in an awkward middle ground. It needs to be built quickly, but it also needs to be stable enough to support real usage.
3. The First Production Release
For other teams, particularly in more regulated environments or established organisations, “MVP” is used to describe the first version of a production system. This version needs to:
- Handle real users reliably
- Integrate with existing systems
- Meet security and compliance requirements
- Be maintainable by a development team
- Support future growth
At this point, the product is no longer minimal in an engineering sense. It may still be minimal in features, but the underlying system needs to be robust. This is where many cost and timeline differences appear.
What Clients Usually Mean
When we are asked to build an “MVP”, the vast majority of the time, the expectation is that it will be deployed and accessible, used by real users, connected to real systems or submitted and available on the App Store or Play Store.
In other words, what is being asked for is not a prototype. It is a releasable product. That expectation is completely reasonable. But it needs to be acknowledged explicitly, because it has a direct impact on how the product should be built.
Why This Matters
These different interpretations lead to very different decisions around:
- Architecture
- Technology choices
- Security
- Testing
- Cost
- Delivery timelines
A prototype might be built in a few hours or weeks. A production-ready release could take several months.
There is also a more subtle risk: technical debt. A prototype is often built with shortcuts. Loose structure, limited validation and minimal concern for long-term maintainability are acceptable when the goal is speed.
The problem arises when that prototype becomes the foundation for a real product. At that point, teams often discover that the quickest path forward is not to improve what exists, but to rebuild it properly. That can come as a surprise.
At GearedApp, we regularly help teams decide whether a system can be evolved safely or whether rebuilding is the more sensible option. In many cases, making the right decision earlier avoids the need to start again later.
Where AI Complicates Things Further
AI has made this problem more pronounced. Teams can now generate working applications very quickly. It is possible to build something that looks and behaves like a real product in a short period of time. This blurs the line between prototype and production.
A system can appear complete while still lacking:
- proper type safety
- structured architecture
- secure configuration
- scalability considerations
The result is something that feels production-ready but has not been engineered to support real-world usage, and this is where many teams run into difficulty when they try to move from demonstration to deployment.
How to Align Early
A useful approach is to define:
- Who will use it
- What level of reliability is required
- What data will be handled
- What integrations are needed
- What happens after the first release
Clarity here reduces risk later. Rather than relying on a single term, it can be helpful to think in stages:
- Prototype
Prove the idea quickly - Validated product
Deliver value to real users and learn - Production system
Build for reliability, scale and longevity
These stages often overlap, but they require different levels of engineering discipline, and trying to treat them as the same thing is where problems begin.
What This Looks Like in Practice
At GearedApp, we see these distinctions play out regularly. Many of the challenges we are asked to solve come from projects where expectations were not aligned early on. The product itself is often promising. The issue is how it was initially framed and built. In practice, most teams asking for an MVP are expecting something that can be released, deployed and used by real users. That expectation is entirely valid, but it means the work required is closer to a production build than a prototype.
This has a direct and significant impact on cost, timelines and how the project is scoped. It also has a direct impact on whether a system can be evolved or needs to be rebuilt.
Being clear about this early leads to better decisions, more accurate quotes and far fewer surprises during delivery. Speed is still important. But understanding what you are building ensures that speed is applied in the right places.
Related Reading
If you are working through similar questions around AI, delivery and product development, these may be useful:
Each explores a different part of the same challenge: building software that is not only fast to create, but viable in the real world.