What is an MVP in software development? The overlooked scope test
On this page
Many founders ask, 'What is an MVP in software development?' and hear that it is a smaller version of the product. That answer is half right. An MVP is the cheapest build that can answer one question about your business. Its size follows from that question, not the other way round.
What is an MVP in software development, in business terms?
Atlassian describes a minimum viable product as the simplest version of a product. It lets teams validate ideas and gather feedback with minimal effort. Wikipedia adds the audience: early customers who can then shape later versions. Martin Fowler's article on Lean Inception states the purpose most sharply. The central property of an MVP, he writes, is that you build it to learn whether continuing is worthwhile. So the product is a means, and the learning is the deliverable.
Three terms get blurred in vendor proposals, so it helps to separate them.
| Term | Question it answers | Who sees it |
|---|---|---|
| Proof of concept | Can this be built at all? | Your own team |
| Prototype | Does the idea make sense when people click through it? | Testers and stakeholders |
| MVP | Will real users adopt it and, ideally, pay for it? | Early customers |
Why the first version should disappoint you a little
Michael Seibel of Y Combinator makes one argument in a YC Startup Library talk on building an MVP. You learn about users only once a product sits in front of them. Surveys can describe a customer's pain, he says, but they do not show you how to solve it. His examples make the point. Airbnb's first version had no payments, no map view, and worked only for conferences. Stripe's first version did little beyond simple card payments for early-stage startups.
The pattern repeats across his examples: fast to build, limited in function, and aimed at a small group. He calls the ideal first users customers whose hair is on fire. They accept an imperfect fix because the problem is urgent. Customers who are not in pain can wait. That filter tells you whom to recruit first and what to ignore. Seibel would rather see a hundred people love a product than a hundred thousand who kind of like it.
Founders often fear that a weak first release ends the relationship with the customer. Seibel's answer is that early adopters are used to imperfect products. People who leave after one bug were never likely to try new software. A demo that goes badly does not end your company, and you can return to the same customer once the product improves.
A scope test you can run in an afternoon
To decide what an MVP in software development should contain, start with one sentence: we believe this type of customer will do this thing because of this problem. Every feature either helps test that sentence or it waits. Seibel's method points the same way. Write the spec down, then cut it by asking whether a truly desperate customer needs each item to start. He also suggests a firm deadline, from two weeks to a month and a half.
Run each feature through four questions:
- Does it help test the one assumption you wrote down?
- Could a manual process or spreadsheet cover it for the first customers?
- Would early customers refuse to use the product without it?
- Does it add obligations, such as payments or personal data, that need legal review?
Fowler's Lean Inception timetable runs a week through personas, features, user journeys and an MVP canvas. It opens with an exercise called Is, Is not, Does, Does not. You do not need the full week to borrow that first exercise. A one-page list of what the product does not do becomes useful quickly. It gives you something to point to when scope pressure arrives.
The size of an MVP follows from the question it has to answer.
Tests that need no software at all
Fowler notes that smaller organisations often take an idea already tested through pre-software MVPs and evolve it into a software product. That sequence deserves a hearing. A landing page, a manually delivered service or a clickable mock-up can answer demand questions for far less than code costs. First Round Review's minimum viable testing process describes an MVP as a basic early version of a product. The same logic applies before any software exists. The limit is clear: manual tests cannot show whether a software workflow survives real use. Treat them as a complement to the build.
What an MVP is not
An MVP in software development is not a buggy product, an investor demo or the first phase of a plan you have already committed to. It still has to work for the narrow job it claims to do. Scope also drives budget, so the cut list comes before any quote. Our breakdown of custom MVP development cost shows how that works. If you plan to build the whole product in stages whatever you learn, you are running a project. You are not testing a business.
What happens after launch, including AI-generated code
Most answers to 'What is an MVP in software development?' stop at launch, so plan the handover before you build. A working MVP becomes the base of your product, and its construction choices stay with you. Pierre Pureur and Kurt Bittner call building a product that is not worth building the costliest mistake. Their InfoQ article on AI-generated MVPs adds that AI can help you test with customers sooner and with less effort. They also warn that AI-generated code is largely a black box. Technical debt can pile up unrepaid until something breaks.
For you, this means asking any partner, human or AI-assisted, one question. How will the MVP be tested for performance, security and ease of change? The InfoQ authors point to empirical testing, such as performance, usability and security testing, as the way to find out. A throwaway MVP is a legitimate choice if you plan to rebuild. A product you intend to grow needs a base that someone can maintain. Decide which one you are buying and write it into the brief. Cost and suitability vary by project, so confirm with a qualified engineering partner what applies to you.
Choosing who builds it
If you want a studio to scope and build the first version, Xerx fixed-price MVP development is one option. Whichever partner you consider, ask for the written scope and the list of exclusions before you sign. A fixed price only protects you when the scope is specific. Our write-up of customized business software examples shows what mature systems can look like.
Action steps
- Write the one assumption: State who will do what, and why. This is the question your MVP exists to answer.
- Cut the feature list: Run every feature through the four questions and move what fails to a later version.
- Try a no-software test: See whether a landing page, manual service or mock-up can answer part of the question first.
- Set a deadline and exclusions: Fix a build window and write a one-page list of what the product will not do.
- Decide the product's future: State whether this is a throwaway test or a base to grow, and ask how it will be tested.
Frequently asked questions
How is an MVP different from a prototype?
A prototype shows how an idea could work, often as a click-through. An MVP is a working product that real early customers use, so you learn from behavior, not opinions.
How long should an MVP take to build?
It depends on scope and team, so no single number fits. Michael Seibel of Y Combinator suggests a deadline between two weeks and a month and a half.
Can AI tools generate an MVP for me?
They can help you reach customers sooner, according to InfoQ's authors, but the generated code is largely a black box. Ask how it will be tested and maintained first.