MVP Meaning Software Owners Should Know, With Real Examples

25 October 2026

The MVP meaning software teams rely on is simple: a minimum viable product is the smallest working version of a product that real users can try, built to answer one question about the business. It is a learning tool first and a product second. This guide covers what the term means in software, what it does not mean, how known products started, and four tests you can run on any MVP scope.

MVP meaning software teams use, in one sentence

Atlassian says Eric Ries introduced the framework, and the definition it gives runs like this: the version of a new product a team uses to collect the maximum amount of validated learning about customers with the least effort. Notice what is missing. There is no feature count and no budget. There is only a question and a way to answer it.

Wikipedia traces the term to 2001, when Frank Robinson coined and defined it, and says Steve Blank and Eric Ries later made it popular. In software the practical reading is this: ship a working core to a small group, watch what they do, and decide the next step from that evidence rather than from the original wish list.

What an MVP is not

Boldare puts it in two lines: an MVP is not just a product with a few features missing, and it is not an early release, though it may lead to one. It calls the MVP an experiment, a way to test one part of your solution.

That has a consequence for scope, and it is the part of the MVP meaning software buyers most often miss. If nobody can say which assumption the product tests, you are looking at a small product, not an MVP. Two neighbours are often confused with it, and the table separates them.

Term Question it answers Who sees it Form
Proof of concept Can this be built at all? Usually the team, internally A small technical experiment
Prototype Does the design make sense? Test users, stakeholders An interactive picture of the interface
MVP Will real users use and want this? Real users A working product with just enough functionality

The first column comes from ScienceSoft’s description of the three terms, and Atlassian’s FAQ gives the same split between internal PoCs and user-facing MVPs. Order is not fixed. Some projects need a proof of concept first because the technology is uncertain, and some skip it.

Why one vendor’s MVP is not another’s

Wikipedia notes that the definition is not formulaic: the words “maximum” and “minimum” force a judgment for each context. Because of that vagueness, the term is used, deliberately or not, for anything from a prototype-like product to a fully fledged one.

You will feel this in sales conversations. One vendor’s MVP is a clickable mockup. Another’s is a complete first release. Neither is wrong by definition, which is why you should ask what the MVP is meant to prove before you compare quotes.

Atlassian describes two later stages that people sometimes mean when they say MVP. A minimum lovable product is built around customer experience, so users like it from the start. A minimum marketable product is the next stage, ready to be sold to early adopters. If a vendor promises an MVP but describes a sellable product with polish and support, you are discussing an MMP, and the scope should be estimated and planned as one. Whatever the label, hold the vendor to the MVP meaning software buyers can verify: a working core, a named question and a real signal.

Real examples, read for the hypothesis

Sources repeat a short list of well-known products that began small. Read them for the question each first version answered, not as proof that small always wins. Together they show the MVP meaning software teams describe in practice: small first, learning second. The “what it tested” column is our reading of the descriptions, not a claim from the sources.

Product First version, per the source What it let the team learn
Amazon An online bookstore (Atlassian) Whether people would buy online from one narrow catalogue
Uber UberCab, an SMS-based cab service (Atlassian) Whether people would request rides by phone
Spotify A landing page used to test streaming technology with beta users (Atlassian) Whether playback could be fast and stable enough to convince labels and investors
Dropbox Basic file storage and sharing (ICAgile) Which extra features users asked for
Airbnb A site called airbedandbreakfast.com (ICAgile) Whether strangers would rent a spare space

One more example from Wikipedia shows a useful split. In 2015 specialists at the University of Sydney built the Rippa robot to automate farm and weed management. Before release, the technical hypothesis, that the robot can tell weeds from crops, was already proven. The business hypothesis, that it would be a viable tool on a working farm, still had to be tested. Software teams make the same mistake in reverse: they prove the technology works and assume the market follows.

For a step-by-step build plan, see our article on how to build an MVP in eight weeks. This page stays on meaning and scope.

Four tests that keep a software MVP honest

These tests turn the MVP meaning software teams quote into a working checklist, built on the definitions above. Run them on any scope document, ours or anyone else’s.

MVP meaning software: four tests of user, job, signal and date for a minimum viable product scope
Four tests to run on any MVP scope before the build starts.
  1. One user. Name the person who will use the first version. If the answer is “everyone”, the scope is a full product.
  2. One job. Write the single task that user must complete. Features that do not serve it wait.
  3. One signal. Decide what you will measure, such as sign-ups or completed tasks, before you build. An MVP without a signal is a demo.
  4. One date. Fix the calendar and let scope flex. Scope that keeps growing is the usual way an MVP stops being one.

A failed test is a result, not a failure. If the signal says users do not want the job done this way, you learned it at the lowest possible cost to your plan.

When an MVP is the wrong tool

The MVP meaning software founders hear in pitches is upbeat, but Wikipedia lists criticism worth taking seriously. Research it cites suggests an early release can hurt a company when a competitor can imitate it and no other barrier exists. Negative feedback on a rough MVP can also damage reputation. Critics add that customers can switch between competing products easily through app stores, and that a product below the expected minimum quality loses to rivals who enter with a higher standard.

Turn that into checks before you commit:

  • Imitation risk. If the idea is easy to copy and you have no other advantage, a public MVP shows your hand.
  • Quality floor. In categories where users expect polish, a rough first version may be rejected, not forgiven.
  • Known need. If the demand is already proven and the workflow is well understood, you may need a full scoped build rather than an experiment. Our piece on when custom software beats off-the-shelf covers that decision.
  • Cheaper tests. A landing page, a manual service or a clickable prototype can answer some questions without code.

Questions to ask a studio that says MVP

Before you accept a proposal, make sure the vendor’s MVP meaning software terms match yours. Ask:

  • Which hypothesis does this MVP test, and in what words?
  • What is explicitly out of scope, and where is that written?
  • Who will see the first version, and how many people?
  • Which event will we measure, and where is it recorded?
  • Who owns the repository, the hosting accounts and the data?
  • What happens after the test: how is the next increment scoped?

A studio that answers in writing, with milestones and demos you can see, is describing an MVP. A studio that answers with a feature list only is describing a small product.

Send the brief, get a written scope

techcraftz writes scope, milestones and the estimate down before the first line of code, then hands over the code, the accounts and the keys. If you want a scoped first version, see our MVP development page. Founders weighing the wider picture can read how we work with early-stage teams. Send the brief or read more about techcraftz.

Last checked: October 14, 2026. Sources describe the term as it is used today; definitions vary by vendor.

Talk to us about your project

Tell us what you need. We help you scope the build, the milestones and a realistic estimate.

View services
Blog

Related guides

Start now

Brief in. Scope out.

Tell us what you need. We will map out the approach, the stages and a written estimate.

08 / Contact

Tell us about your project

Fill in the short form below. We will reply with questions or next steps and, once the scope is clear, a written estimate.

Service area
Worldwide (remote)

Enter your name.

Enter a valid email so we can reply.

Choose a project type.

Tell us briefly what you want to build.

Your details are used only to respond to this request.