What MVP Means in Software Development, and What It Does Not

In software development, MVP stands for minimum viable product: a deliberately limited product used to test a consequential assumption with real users. Its scope follows the question. No universal screen count, price or delivery time makes a release an MVP. It must be usable enough for the intended test, with the safety, permissions and reliability that task requires. Our own five-day sprint limits are commercial scope boundaries, not the definition of the term.

Key Takeaways

• Define the assumption and evidence before counting features.
• A prototype can produce useful evidence without proving sustained use.
• A proof of concept concentrates on feasibility and can involve users.
• MVP and beta describe different dimensions and can overlap.

The definition that survives contact with practice

Eric Ries's 2009 MVP guide frames the work around customer learning while minimizing unnecessary effort. The implication is that size alone does not define an MVP. The experiment needs to teach the team something that changes a decision.

That reframe changes what you build. Alongside the budget, ask what evidence would change the next decision. A marketplace might test whether suppliers will fulfil a request; a subscription app might test repeat use. Neither question is mandatory for every product. Include the work needed to collect credible evidence, including permissions, failure handling and participant support.

Before a sprint, we write a learning question and the decision it informs. The one-page strategy exercise helps connect that question with the customer and scope. A written question makes tradeoffs easier to discuss; it does not eliminate disagreements about risk, evidence or implementation.

What an MVP is not

Not simply another word for prototype. A prototype can be a sketch, a clickable design or working code. It can reveal comprehension, usability and reactions to an offer. A realistic pilot can also capture behavior. State what participants actually did and what remained simulated; stated interest alone does not establish sustained adoption or payment.

Not simply another word for proof of concept. A PoC focuses on feasibility: an integration, model output or technical constraint. It may involve users when their tasks define success. A functioning connection alone does not establish demand. Decide which experiment to run first from the most consequential uncertainty, not a compulsory sequence.

Not the same label as beta. Beta describes a release or testing stage; MVP describes a learning strategy and deliberately limited scope. A product can be both. Settings or an admin panel do not disqualify it if they are necessary to run the experiment responsibly. Ask what the release must teach you and which work is needed to obtain that evidence.

Not automatically any small first release. A small release needs an explicit learning purpose to be useful as an MVP. Reducing scope is different from omitting protections the task requires. A manually supported service or constrained pilot may be enough; a sensitive transaction may need substantial engineering. Explain limitations to participants and preserve the reliability necessary for the test.

What one looks like, concretely

Our Product Sprint is one commercial example: $9,000 for an agreed five-business-day scope, up to ten screens and one or two flows, with design and code handoff. Those limits describe the offer, not a technical maximum or a definition of MVP. Integrations, data sensitivity and release approvals can make a seemingly small product unsuitable for it.

The PaceCalc project illustrates a tightly bounded utility. ILTY illustrates a much broader eventual product. Their case studies describe delivered work, but neither the final feature count nor the test count identifies the exact first experiment. To evaluate an MVP, retain its original question, participant conditions and observed results.

When not to build one

Choose a smaller experiment when it answers the question. A landing page can measure response to a message, but not whether people can complete the product's core task. An existing customer's feature request may need a prototype or limited rollout before a full build. Compare the cost and limitations of each experiment; MVP budgeting explains the scope questions.

The one-paragraph answer

MVP means minimum viable product: a deliberately limited product or service experiment used to learn from real users. Specify the assumption, participants, task, evidence and next decision. Prototypes and PoCs can contribute useful evidence; beta is a release-stage label that can overlap. No screen count or timetable settles the definition.

Scope and pricing referenced here are SUUR's published sprint terms, current on 2 September 2026.