What is an MVP? How to launch a software product without building everything first

If you are planning a software product, whether to sell to customers or to run your own business, someone will tell you to build an MVP first. It is good advice, and it is often misunderstood. Here is what an MVP actually is, what it is not, and how to plan one.

The definition

A minimum viable product is the smallest version of a product that real users can use to achieve something they want, and that gives you real information about what to build next.

Three words matter. Minimum: the fewest features that make it useful. Viable: it actually works, end to end, for the core job. Product: real people use it for real purposes, not a demo.

What it is not

Not a prototype. A clickable prototype shows what a product might look like. It is useful for testing a concept, but nobody uses it to get work done.

Not a cut-down version of everything. An MVP that has a little of every planned feature, none of them complete, is the worst of both worlds. Better to have one feature that fully works.

Not low quality. Minimum features, not minimum standards. It should be secure, reliable and pleasant enough that people keep using it.

Why build one

Because you do not know what users need until they use something. Every product plan contains features that turn out to be unnecessary and misses ones that turn out to be essential. Finding that out after building everything is expensive. Finding it out after building the core is cheap.

An MVP also gets you revenue, or internal value, months earlier than a full build would.

How to decide what goes in

1. Write down the single job the product must do. One sentence. "Let a tradesperson send a quote from their phone in under two minutes."
2. List every feature you have imagined.
3. For each, ask: can a user complete the job without it? If yes, it is not in the MVP.
4. What remains is the MVP. It is usually smaller than feels comfortable. That is the point.

Common things that feel essential and usually are not: admin dashboards, reporting, multiple user roles, settings pages, integrations with everything, native mobile apps when a mobile web app will do.

Build it to grow

Minimum features does not mean throwaway code. The data model, security and architecture should be built so that the next features fit without rebuilding. This is where an experienced team earns its fee: they know which corners can be cut and which cannot. Our guide to agile and sprints explains how the build is organised so that each sprint delivers something usable.

Launch, measure, learn

Put it in front of real users as soon as it does the core job. Then watch: what do they do, where do they get stuck, what do they ask for. Talk to them. The next version is built from that evidence, not from the original plan. Google Analytics and simple feedback forms are enough to start; see our GA4 basics guide.

An example

A business wants a customer portal with ordering, invoices, documents, delivery tracking, returns, live chat and a mobile app. The job customers most want done is reordering without emailing. The MVP: log in, see previous orders, reorder with one click, see order status. Everything else waits until reordering is proven. In practice, reordering alone often removes most of the emails, and the priorities for the rest change once customers are using it. See customer portal benefits for what typically comes next.

Cost

Because scope is small, an MVP is the most affordable way to start a product. Our custom software cost guide gives ranges. We scope MVPs on a free discovery call and quote them at a fixed price. Read about our custom software service or request a quote.

Frequently asked questions