What is an MVP, and what you will have to cut
Plenty has been written about MVPs, and most of it is the same definition. The definition is not the problem — everyone agrees on it. The problem is that in practice something has to be cut, and that is where teams start arguing. This article is about the cutting.
The definition, to get it out of the way
An MVP, or minimum viable product, is a version of a product with the smallest set of features that is still usable and still tests your main hypothesis. The term came from Frank Robinson and was popularised by Eric Ries in The Lean Startup.
The key word is hypothesis. An MVP exists to learn something. If you cannot say what you are trying to find out, you are not building an MVP — you are building a first version.
Why most "MVPs" are not
The most common mistake is to call a full product with stripped-down design an MVP. The result is a project that has everything — sign-up, profiles, settings, notifications, admin panel, pricing tiers — and none of it finished. Users see something raw, the team burns the budget, and the main question is still unanswered.
The opposite happens too: so much is cut that there is nothing to test. A landing page with a "coming soon" button tests interest in an idea, but says nothing about whether people will use the product regularly.
How to decide what goes in
A method that works: walk the feature list asking one question — "If this is missing, can we still learn what we want to learn?" If yes, it leaves the MVP. The question is simple; applying it consistently is not, because almost every feature has an "it's awkward without it" argument. Awkward is not the same as impossible.
The second filter is one user's path from start to finish. Pick the main flow and make it work end to end: entry, the core action, the result. One flow that works beats five that half-work.
The third is an honest list of what you already know and what you do not. Only the second needs testing.
What to do by hand instead of in code
Automation is the most expensive part of a product and the most optional at the start. While you have tens of users, many things are cheaper done manually:
- Moderation and verification — by eye, not by algorithm.
- Matching and recommendations — by hand, until you understand the rules.
- Invoices and refunds — a bank transfer and a spreadsheet.
- Mailings — from an email service, not your own system.
- Analytics — an export to a spreadsheet instead of a dashboard.
Manual work early is not a hack. It is how you learn the rules before you write them into code. Rewriting a badly automated process costs more than automating a well-understood one.
How this looked on our projects
Rivopost. Running a Telegram channel end to end means monitoring sources, filtering noise, drafting posts, planning a calendar and publishing on schedule. Build all of it at once and the first version never ships. The one thing worth testing: will a channel owner hand publishing over to an external service at all?
Kursly. An exchange-rate aggregator could have started with a dozen venues, user accounts and deal history. The hypothesis was narrower: will people come back for a comparison that accounts for each venue's real fee, not just the headline rate? For that you need accurate data from a few venues and a working calculator.
BelTimberExport. For B2B export the temptation is a full buyer portal with orders and documents. What actually needed testing first was whether Chinese buyers would reach a structured enquiry at all: a catalogue of species, volume and container-loading calculators, and a step-by-step form.
MVP, prototype and proof of concept
The three words are often used interchangeably, but they answer different questions.
- A prototype answers "is this understandable?" Clickable mockups, nothing works underneath.
- A proof of concept answers "is this technically possible?" It tests one risky piece, such as recognition accuracy or processing speed, and users never see it.
- An MVP answers "will anyone use this?" A working product in real people's hands.
Four mistakes that cost real money
No success metric. Before launch, agree what result counts as confirming the hypothesis and what counts as disproving it. Without that you will argue about interpretation afterwards.
No analytics. An MVP without events tracked is spending blind: you will see that users left, but not at which step.
Scope creeping quietly. Agree up front that a new feature enters the MVP instead of another one, never in addition.
"Throwaway" technical decisions. The first version always lives longer than planned. Speed beats perfection, but a database and an auth layer built carelessly will come back.
Questions people ask
What is an MVP in simple terms?
The first working version of a product that contains only what you need to test the main idea. It is usable, but deliberately narrow.
What does MVP stand for?
Minimum viable product. In sport and gaming the same abbreviation means most valuable player — a different meaning entirely.
How is an MVP different from a prototype?
A prototype shows how a product looks and feels but does not work underneath. An MVP is a working product that real people use and that you collect data from.
How long does MVP development take?
It depends on how narrowly the flow is defined. The main factor is not team speed but discipline in saying no to features. Projects that fix scope after discovery ship noticeably faster than those that add features as they go.
What happens after an MVP launches?
You look at the metric you chose in advance and decide: build on it, pivot, or stop. An MVP that changes none of your plans has not done its job.
