A founder has a software idea, no users and a limited budget. An mvp minimum viable product answers one question first: will real customers use and pay for this? Build the smallest working version that can answer it.
This guide works through the beliefs that most often send first builds off course, then gives a test-first workflow and decision rules. It sits within our software startup guide, which places the MVP in the wider startup journey.
What an MVP is, and what it is not
A minimum viable product is, per NetSolutions’ MVP guide, a stripped-down, low-risk software application with basic features, used to gather feedback from early adopters. Its purpose is to establish product-market fit with the least effort, so it includes just enough features to solve the problem the app was designed to solve. Product-market fit is the outcome you are testing for. The MVP is the instrument that tests it.
According to a software-development explainer, the primary goal is to learn whether customers will use and pay. That makes the MVP a test of market viability and business assumptions, not a feature-complete product. Write that question as one sentence before you sketch any screen. Everything you build afterwards should earn its place by helping answer it.
The most common mix-up is with a prototype. The two look similar on a screen but do different jobs.
| Question | MVP | Prototype | Planning use |
|---|---|---|---|
| What is it? | A fully functional software application, albeit a very basic one | A model of the product | Choose an MVP when the question is about behaviour, not appearance. |
| Is it released? | Yes, it is a released product | No, it is only the model of the product | Only a released product can show whether people use or pay for it. |
The distinction comes from NetSolutions and the SendPulse glossary. The same explainer notes that, unlike prototypes, MVPs must be functional enough for real customers to use. A prototype is still useful for settling a layout. It cannot tell you whether anyone will come back to the product.
Misconception: an MVP has to be a finished app
The word “product” misleads many founders into building a complete application. The evidence points the other way: several well-known MVPs were deliberately thin, and each tested a different assumption.
- A landing page. SendPulse describes this MVP type as a page that lays out the product’s advantages and offers either a purchase or a coming-soon signup, which also collects emails. A purchase option tests more than a signup does, so use it when willingness to pay is your riskiest assumption.
- A video. The founders of Dropbox used a video explaining how the product worked as their MVP at its 2008 launch, according to NetSolutions. A video suits products that are hard to describe in a sentence and expensive to build before anyone has shown interest.
- A single feature. In 2009, Foursquare launched as a single-feature app built around location-based check-ins and expanded later, as this LinkedIn article recounts. One core action is easier to measure than a bundle of features.
These examples and the “fully functional” definition fit together once you match the form to the question. A landing page or video tests interest in a promise. A basic working app tests whether people use the product and pay. Pick the lightest form that can still disprove your riskiest assumption, and move to working software only when the question is about use or payment.
Building an MVP for a software startup
A test-first build runs in a fixed order, and the metric is settled before the first line of code.
- Define the value proposition. The same explainer puts this first: state the core problem you solve and the value you provide before choosing any features.
- Set the success metric and threshold. Decide what result would count as demand while the idea is still neutral. A target chosen after the data arrives will bend toward whatever the data shows.
- Cut the feature list. Keep only what solves the core problem. Rank each candidate feature by whether removing it would stop the test from working.
- Build in measurement. A good MVP includes mechanisms to measure user behaviour, collect feedback and validate assumptions. Analytics and a feedback channel belong in the first release, not a later one.
- Release to early adopters. Launching starts the validation of the product’s viability in the marketplace. It is the first major step, not the end.
If the test depends on public attention, the guide on how to launch on product hunt covers one route to reach early adopters. A smaller, targeted group of early users usually gives a cleaner signal than a broad audience.
Misconception: a launch proves demand
A launch with no measurement proves nothing. Demand shows up in what users do, so the numbers you set in advance matter more than the launch itself. The explainer cited above offers illustrative targets for a software MVP:
- Adoption: Active users within the first month, measured against a target set before launch.
- Retention: 40% of users return after first use.
- Engagement: a 5-minute average session.
- Monetisation: 20% free-to-paid conversion.
- Satisfaction: Net Promoter Score (NPS) measured against a target set before launch.
Treat these as examples of the kind of metric to choose, not as benchmarks your product must hit. The right threshold depends on your market and price, so write your own and keep it fixed through the test. Choose one primary metric and read the others as context. Retention and conversion are harder to flatter than raw sign-ups, which makes them the better evidence that people want the product.
An MVP also lets owners analyse demand before committing to a large investment, as SendPulse notes. That only works if the analysis can happen, so confirm that your analytics capture the primary metric cleanly before you release anything.
Decision rules: pivot, persevere or scale
After the test, the explainer lists four options: pivot based on what you learned, add features users are requesting, remove features nobody uses, and improve the features that exist. The list does not say when to choose each. These rules are a judgement that turns it into a decision, and they work only when the thresholds were fixed beforehand.
- Persevere when the primary metric meets its threshold. Improve the existing features first, then add the ones users request.
- Pivot when the metric misses but feedback points to a different user, problem or core action. Change one of those, run a new MVP cycle and keep the old result as a baseline.
- Trim when specific features go unused. Removal is a decision too, and it makes the next test cleaner.
- Scale only after the thresholds have been met and the product has been improved on the evidence. Scaling a result that has not been repeated builds on a guess.
If neither the numbers nor the feedback point anywhere, the idea itself is the problem rather than the build. Redirect the effort instead of adding features. Once you have results worth showing, What Is A Pitch Deck? The Startup Guide To Winning Investors In 2026 – Interestingdevelopment helps turn them into an investor conversation.
Frequently asked questions
| Question | Answer |
|---|---|
| Who introduced the MVP concept? | According to NetSolutions, Frank Robinson first introduced the concept in 2001, and Eric Ries, author of The Lean Startup, popularised it. |
| How much does an MVP cost, and how long does it take? | Cost varies greatly with scope and complexity, technical requirements and design requirements, so another product’s budget is a poor guide. For timing, Twitter’s team loved its internal SMS MVP and then spent six months building the product, so the MVP is the first test rather than the whole build (NetSolutions). |
| Why test with an MVP instead of building the full product? | Published startup-failure figures vary widely. SendPulse cites around 20% failing in the first year, while a LinkedIn article cites almost 90% of new startups failing. Whichever figure you trust, a small test costs far less than a full build that nobody wants. |
