Anyone who wants to define an MVP for a new software product must first identify a question that can be answered by the first version. It is precisely this question that is missing from most scoping workshops, which instead begin with a list of features. Entrepreneur and author Eric Ries introduced the term in his book The Lean Startup defined the MVP as the version that enables maximum validated learning with minimal effort. “Minimal” here refers to the scope of features, not to the quality of implementation.
Defining an MVP means prioritizing the learning question over the feature list. The scope of the first version includes exactly what is needed to answer that one question with real users. “Minimal” refers to the number of features, not to quality, security, or compliance. Without the learning question, the result is not an MVP, but a scaled-down final product.
What an MVP Really Is
According to Ries, validated learning refers to the reaction of real users to a real product. In this sense, an opinion from one’s own team does not count as validation. This allows the MVP to be distinguished from two related concepts that are often confused in projects. A prototype is disposable and has no real users; it serves to validate an idea internally or to facilitate a discussion with a customer. An MVP, on the other hand, is already a real product with real users, even if it is still small. A beta version, in turn, is nearly complete and serves primarily to put the finishing touches on the product before a broad rollout.
| Form | Real users | Purpose |
|---|---|---|
| Prototype | no | Test an idea internally or during a meeting with a client; it can be discarded afterward |
| MVP | yes | Answer a study question with the smallest feasible scope |
| Beta version | yes | Final touches before the full-scale rollout |
A real-world example illustrates the difference. A retail company that wants to test whether its field sales representatives would even use a digital order form does not need a full integration with the inventory management system to do so. A form that initially forwards orders via email to the back office is sufficient to answer the actual question. If the target group adopts the tool, integration with the existing systems follows only afterward.
Defining MVP: The One-Sentence Test for Scoping
A practical test drawn from scoping practice helps clarify the distinction. If the project can be formulated as a sentence beginning with „We’re building this to find out whether…,“ then it’s an MVP. If such a learning question is missing, it’s usually just a scaled-down version of the final product with fewer features. According to a classification by Refact In the context of 2026, “minimum” refers to the smallest scope that answers a question, not the cheapest scope. According to Refact (2026), security and compliance requirements remain in place even in the MVP. They are not among the elements that can be cut during the scoping phase.
The Most Common Scoping Mistakes
According to an analysis by Identify Digital In the 2026 case, three mistakes in particular recur during the scoping phase. The first is the absence of a learning question; the team starts with a feature list instead of a hypothesis that could be disproved. The second is a feature list without any real prioritization, where in the end almost everything ends up being marked as a „must-have.“ The third is planning for tomorrow’s users instead of today’s—for example, designing an architecture to accommodate 100,000 users even though the first 50 test users haven’t been recruited yet.
A lack of learning questions, a feature list without real prioritization, and planning for tomorrow's users instead of today's—these issues keep cropping up when designing the first version.
Identify Digital, 2026
Small teams tend to make the first mistake because it’s harder to formulate a learning question than a feature list. Larger organizations tend to fall into the third category because they usually already have a vision of the final product before the first user has even seen anything. All three mistakes have similar effects. The MVP grows before the first line of code is written, losing the speed that originally made the approach attractive.
When the MVP Approach Isn't the Right Fit
This approach assumes that an unfinished product can be reasonably expected to be accepted by real users and that failure on a small scale is permissible. For software subject to high regulatory barriers—such as in medical technology or safety-critical plant engineering—this assumption does not apply. In those cases, an unfinished product cannot simply be given to real users because approval, documentation, and liability must be established from the outset. In such cases, what can be validated shifts from the software itself to individual components—such as a user interface tested in a lab rather than on the finished device. A common solution is a two-step approach. The risky technical assumptions are tested in a controlled environment—for example, with a limited group of users under expert supervision—while the formal requirements are fully implemented from the very beginning.
After the MVP: Contract and Next Steps
Once you’ve defined an MVP, you’re soon faced with the next question: How will further development be governed by contract? After a successful MVP, the nature of the collaboration often shifts from an exploratory phase to a project with clearer requirements. Which „contract model is appropriate for the respective phase“ depends on the degree of uncertainty, which is usually significantly lower after a successful MVP than it was at the beginning. This article shows how these clearer requirements can be documented in a structured manner. Writing a Requirements Specification: A Guide with a Template.
This approach relies on the idea that an unfinished product is acceptable to real users. In medical technology or safety-critical plant engineering, this does not apply; in those fields, regulatory approval, documentation, and liability are established from the very beginning. Likewise, the distinction between a prototype, MVP, and beta version is not a fixed standard but rather an agreement within the project. If you don’t document these distinctions in writing, you’ll end up arguing about expectations rather than results later on.
Get to the heart of your own learning question
Whether a project can truly be phrased as „We’re building this to find out if …“ often becomes clear only after discussing it with someone outside your own team. An initial discussion walks through the planned scope of functionality using this test.
Frequently Asked Questions
How long does an MVP take?
There is no set timeframe, because it depends on the learning objective rather than a calendar-based goal. In practice, technically simple MVPs often take between six and twelve weeks, while projects that integrate with existing systems—such as an ERP—take significantly longer. A red flag is when an MVP takes longer than the planned lifespan of the question it is meant to answer. In such cases, the scope has usually expanded without anyone noticing.
What should definitely not be included?
Anything that doesn't directly answer the learning question shouldn't be included at first, even if it will be needed later. This typically includes multilingual support for markets that are not yet being served, a detailed roles-and-permissions model for user numbers that have not yet been reached, or reporting functions that no one looks at during the testing phase. As described, security and compliance requirements that apply from the very beginning are exempt from this rule.
What happens after the MVP?
The MVP is typically followed by an evaluation phase, during which the learning question can be answered using real usage data, rather than opinions from the sales team. If the hypothesis is confirmed, the product progresses toward a beta version and then toward a fully-fledged system. If it is not confirmed, the MVP has still served its purpose. The first version was built precisely to achieve this outcome.
At torck, the development teams in Maxhütte-Haidhof, Vienna, and Rabat regularly take on the task of tailoring an MVP so that the focus remains on the learning objective rather than the department’s wish list. Contracts are handled through the German company torck GmbH, which provides a sense of security—especially for a first joint project without a long history of collaboration. Because torck Custom Software When building solutions for industry and commerce, the teams are aware of the pitfalls that arise when an MVP needs to be integrated with ERP or machine data later on. A Initial Consultation determines what scope is realistic for the first version.
German 
English 
French