MVP (minimum viable product) — what it is and how to cut a scope that answers one question

Most projects labelled "MVP" — minimum viable product — are actually full applications with the budget cut. Someone has a list of thirty features, a contractor quotes a sum the client doesn't have, and both sides agree to "start with an MVP" — meaning the same thirty features, built faster and cheaper. A few months later, out comes a product that tested nothing, because nobody decided what to test.

An MVP is something else. It's the smallest product that answers a single business question — and that question, not the budget, sets the scope. So the hardest part of an MVP isn't the programming; it's writing down what you're not building. This article shows how: how an MVP differs from a proof of concept and a prototype, how to cut scope with MoSCoW, what to measure the result against, and what expanding it looks like once you have an answer. The examples come from tools we built for ourselves — with dates, because those can be checked.

What is an MVP (minimum viable product)

MVP stands for minimum viable product. The term was popularised by Eric Ries, author of the lean startup methodology, and his definition is still the most widely quoted: "the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" (Eric Ries, "Minimum Viable Product: a guide", 2009).

Two words carry the weight. The first is learning — an MVP isn't primarily a product to sell, it's a tool for testing an assumption. The second is viable, which means capable of actually working — an MVP has to function in the hands of real users. A mock-up, a pitch deck or a survey can be a good first step, but none is an MVP: none lets you measure real use.

Lean startup: build, measure, learn

Lean startup, the approach the term comes from, runs on a short loop: build the smallest thing, measure how people use it, draw a conclusion, decide what to do next. The MVP is the first turn of that loop. If no decision follows it, the loop hasn't closed.

There are, in practice, three decisions you can make after measuring. You can build on it — the result confirmed the assumption, so the next turn adds another feature and another question. You can change direction — people are using the product, but not as expected, and that's more valuable than confirmation; lean startup jargon calls this a pivot. Or you can stop — a good outcome too, if it cost weeks instead of a year. An MVP after which none of these three is possible, because the result is "a bit yes, a bit no", usually didn't have a measure written down in the first place.

This loop only works if each turn is short. So the real constraint on an MVP isn't the budget — it's the time to the first measurement: the faster real users get something working, the sooner you'll know whether the rest is worth building.

MVP, proof of concept and prototype — three different questions

In conversations about a new product, these three terms get used interchangeably, and each one means a different outlay and a different result. The simplest way to tell them apart is by the question each one answers:

A proof of concept makes sense where the biggest risk is technical: you don't know whether an integration with a supplier's system is even possible, or whether an algorithm can cope with the data. A prototype belongs where the risk is usability; we cover what a prototype looks like and what comes out of it in our article on the app development process. An MVP belongs where the risk is whether anyone needs this at all. These three can run one after another, but none replaces the others.

What an MVP is not

It's easier to understand an MVP by what it isn't, because the same three mistakes turn up in almost every project.

An MVP is not an unfinished app. A version where half the screens are empty and the rest "mostly" work won't give a reliable answer — a user will reject it because of what's missing, not because the idea is bad. An MVP has a small scope, but within it, it works properly.

An MVP is not a bug-ridden beta. Bugs in an MVP cost just as much as in a full version, because they corrupt the measurement: you can't tell whether someone gave up because they didn't need the feature, or because it crashed.

An MVP is not "everything, just cheaper." Lowering quality while keeping the same scope isn't a minimal version, it's a worse full version. Savings in an MVP come from cutting features, not from rushing.

An MVP doesn't always have to be an app

Since an MVP has to answer a question, not look finished, a person can do part of its job. This is sometimes called a concierge MVP: the user sees a simple form or panel, and whatever's meant to happen behind it is, at first, done manually by someone on the team. The measurement is the same — whether people use it — and the cost is far lower, because the most expensive part, automation, only gets built once you know it's needed.

Our own call-booking module started exactly this way, as we cover below: a form with a date, and a booking confirmed by hand. For the user, it worked — it booked a call. For us, it answered whether booking through the website made sense at all, before we paid for a proper availability engine.

This has a limit: the manual work has to be sustainable at whatever scale the MVP needs for its measurement. A dozen or so requests a week — fine. A few hundred a day — no, and that's when automation stops being a cost paid in advance and becomes a precondition.

The MoSCoW method — how to cut scope

The most practical tool for cutting scope is the MoSCoW method, a prioritisation technique in which every requirement is placed into one of four categories. The Agile Business Consortium, the organisation behind the DSDM methodology, defines them as follows (Agile Business Consortium, What is MoSCoW Prioritization?):

• Must have — "the minimum usable subset of requirements which the project guarantees to deliver";
• Should have — "important but not vital";
• Could have — "wanted or desirable but less important";
• Won't have this time — requirements "which the project team has agreed will not be delivered" in this timeframe.

In an MVP, the Must category should be as small as possible — only what you can't answer the question without. The Won't category matters just as much and gets skipped most often. If you don't write down what you're deliberately not building, those features come back mid-project as "small extras", and three months later the MVP is a full app again.

How to run MoSCoW on your own list

Start by writing down every feature anyone in the company has mentioned, without judging any of them. Then ask one question of each item: can we answer the MVP's question without this feature? If not — Must. If yes, but the product will be noticeably worse — Should. If yes, and few will notice — Could. Everything left goes into Won't, with a date to revisit it.

Two rules keep the split honest. First: Must can't be the biggest category — if it is, everyone has defended their own feature and nothing has actually been cut. Second: the Won't list is signed off by whoever approves the budget. A feature that comes back mid-project then comes back with a question about what gets dropped in exchange, not as a "small addition".

Example: scoping the first version of our own CRM

When we built our own CRM in July 2026 — the contact database every enquiry from this website lands in — we wrote the scope in exactly these categories, under different names: "phase 0", "later, kept, not dropped", "deliberately not doing this". Two months on, here's what happened to each item:

Two things here matter more than the split itself. First, the Could item was only built once there was a concrete reason, not once it seemed useful. Second, one item was never built — and that's a result too: had it gone into the first version, we'd have paid to solve a problem that doesn't exist. We cover how similar decisions play out when choosing between an off-the-shelf system and your own in our article on CRM for small businesses.

One question, one measure

Scope is half of an MVP. The other half is the measure — it's what separates an MVP from a version that "went well" only because nobody checked whether it did.

Before you build, write down three things. The question: one sentence the MVP has to answer, for example "will our customers place orders themselves instead of phoning." The measure: a number that answers it, for example the share of orders placed through the panel in the first month. The threshold: the value above which you consider the assumption confirmed, and below which, disproved. Plus a date to measure by — an MVP with no read-out date never ends.

The threshold has to be written down before you start. After the fact, any result can be dressed up as promising — twenty per cent becomes "already one customer in five", five per cent becomes "a good start". A threshold set in advance removes that freedom, which is exactly why it's needed.

Product-market fit — when an MVP stops being an MVP

When the measure keeps rising without being forced — customers come back, they recommend you, enquiries arrive unprompted — people talk about product-market fit. An MVP isn't meant to prove that. It's meant to show whether it's worth heading that way, and to say honestly when it isn't.

We won't give a threshold at which product-market fit begins, because the numbers circulating online describe consumer products and tech start-ups, not a business tool. The signals, though, are recognisable without thresholds. First: users come back unprompted — in a customer-facing app that's repeat logins, in an internal tool it's the old way of working falling out of use. Second: requests for new features extend what's there rather than fix the basics. Third: if the product disappeared, someone would complain.

Once these appear, an MVP stops being an experiment and becomes a product. The way of working changes too: one question and one measure give way to a development plan, and the smallest possible scope gives way to a scope that has to be maintained, tested and extended without breaking what already works.

After the MVP: expand it when there's a reason to

The most expensive mistake after an MVP is an expansion plan written on day one and followed regardless of what the measurement showed. New features are worth adding when actual use calls for them — and you can see this in the history of the module used to book a call on this website.

The first version, from December 2024, was a form with a date: name, email, subject, message, start and end time — and a "confirmed" field ticked by hand. No available slots, no calendar, no automatic confirmation. It answered one question: would people book a call through the website at all, instead of emailing.

Automatic slots, public holidays, cancelling and rescheduling, and the Google Calendar connection arrived in June 2026, over eighteen months later, once confirming bookings by hand cost more than automating it would. Any earlier, and the same work would have been answering questions nobody had asked yet.

It was much the same with our web application cost calculator and its sister calculators: they launched in March 2026 with three configurations — a website, a shop and a web application. There are eight today, each added only once the first three showed the tool was actually being used.

How long an MVP takes, and what it costs

The honest answer to both is: as much as the Must category. So we won't give you a range here — any pair of numbers without a defined scope is a guess.

There's no published Swiss benchmark for MVP pricing we'd stand behind. The price of an MVP is the price of its Must list. Our web application cost calculator prices this in Swiss francs, and our article on app development cost walks through what that price is made of.

Time works the same way. Every Must-have feature adds its own slice to the schedule, and some add a lot — in our rules, a customer login area alone adds two to four weeks. More important than a "ready by" date is the measurement date: the day you read the measure and decide. Fix that, and the threshold, before you start.

We won't promise funding either: public grant programmes differ by country, so check your own before planning around one.

MVP scope checklist