What is an MVP, and what should actually be in yours?

An MVP, or minimum viable product, is the smallest version of a product that lets real customers get real value from it, so you can find out whether they will pay before you build the rest. For software, that usually means sign-up and login, one core workflow done well, a way to pay, and a way to reach you. Everything else waits until paying customers ask for it.

The word "minimum" gets the attention, but "viable" is the part people skip. A viable product solves the problem well enough that someone would choose it over what they do today. A half-working version of ten features is not viable. A finished version of one feature often is.

What does MVP actually mean?

The term was coined by Frank Robinson in 2001 and spread through Eric Ries's book The Lean Startup. The idea is simple: every new product rests on a few guesses. People have this problem. They will pay to solve it. They will pay this much. They can find you. An MVP is the cheapest thing you can put in front of customers that tests the riskiest of those guesses with real behaviour, not opinions.

That framing explains three common confusions:

• An MVP is not a prototype. A prototype shows how something would work. Nobody depends on it. An MVP is used for real, which is why it needs login, data that persists and a way to pay.
• An MVP is not a bad first version. It is narrow, not sloppy. The one workflow it covers should work reliably, because a customer who hits bugs will leave before you learn anything about demand.
• An MVP is not always software. If the riskiest guess is "will anyone pay", a landing page with a payment link can test it in a week.

What kinds of MVP are there?

Pick the type by the guess you most need to test. Building software is the most expensive way to learn and should come after the cheaper tests have passed.

A pre-sale page does not need a developer. Stripe's Payment Links let you take a payment or start a subscription from a shared URL without writing code, which is enough to test whether a price works. A concierge MVP means doing the job yourself: if the product will reconcile timesheets, reconcile them by hand in a spreadsheet for three customers and charge for it. You learn what the customers actually need faster than any build would show you.

Only when those tests pass is a software MVP worth the money. That is the stage our web app and SaaS development work usually starts at, and the stage the rest of this guide is about.

What must be in a software MVP?

Six things, in our experience. Leave any of them out and you either cannot learn from the MVP or cannot keep the customers it wins.

1. Sign-up and login. Email and password, a magic link or Google sign-in. One method is enough to start.
2. The core workflow, end to end. The one job a customer came for, from the first input to the result they take away. No dead ends and no "coming soon" buttons inside it.
3. A way to pay. A subscription with a trial, or a one-off payment. Billing affects the data model, so it is cheaper to build in from the start than to add later.
4. A way to reach you. A support email or chat. Early customers who can reach you tell you why they stayed or left.
5. A basic admin view. You need to see who signed up, what they did, and to fix an account without touching the database by hand.
6. Error tracking and backups. When something breaks for a paying customer you need to know before they email you, and you need to be able to restore their data.

What should you leave out?

Almost everything else. These are the features founders most often want in version one that rarely change whether the first customers pay:

• Team accounts, invitations and multiple roles. Start with one user per account unless the product only makes sense for a team.
• A mobile app. A responsive web app works on phones; a native app doubles the build and adds store review. See the mobile app development guide for when an app is worth it.
• Integrations beyond the one that matters most.
• Analytics dashboards and reports. A CSV export covers the first months.
• Settings pages for every preference. Pick sensible defaults.
• A public API, white-labelling and custom domains.
• Bespoke visual design. A clean component library with your logo and colours is enough.

The test for any feature is one question: can the first paying customer get the result they came for without it? If yes, it waits. How to scope an MVP in one week turns that question into a method, and how much a web app costs shows how much each extra role, integration and screen adds to the budget.

How do you know whether the MVP worked?

Decide before you build, and write it down. Without a target set in advance, any result can be read as encouraging.

A useful success criterion names a behaviour, a number and a date. "Ten paying customers within eight weeks of launch, and at least seven of them still active in week twelve." Or, for a B2B product with a higher price: "three signed annual contracts from the fifteen companies we interviewed."

Activity counts like sign-ups and page views are weak signals on their own. Payment and repeat use are strong ones. Once you have prices and early churn, our LTV calculator shows what a customer is worth over their lifetime, which tells you how much you can afford to spend winning the next one.

If the MVP misses its target, the useful question is which guess failed. People did not sign up: the problem or the message is wrong. They signed up but did not finish the core workflow: the product or the onboarding is wrong. They used it but did not pay: the price or the value is wrong. Each answer points at a different next step, and only one of them is "build more features".

When is an MVP the wrong approach?

The MVP idea came from consumer and SaaS startups, and it does not fit everything.

Replacing an internal system. If your staff must stop using the old tool on the day the new one goes live, a version that covers a third of their work is not viable. Internal tools need the whole of one process, which is a different scoping exercise. Custom software vs off-the-shelf covers that decision.

Regulated products. Health, finance and anything handling sensitive personal data have a minimum set of security and compliance requirements that cannot be cut. The MVP is smaller than the full product, but its floor is higher.

Marketplaces. A marketplace needs both buyers and sellers to be viable. The MVP is often a manual matching service on one side, not a product for both.

Products where quality is the value. If you are entering a crowded market by being better than the incumbents, a minimal version proves only that the minimal version is worse. Narrow the audience instead of the quality.

In each of these cases the principle still applies: test the riskiest guess first, as cheaply as you can. The output just looks less like a stripped-down app. The pillar guide, how to build a SaaS product, shows where the MVP sits among the other steps, from validating the problem to the numbers that decide whether to keep going.