An MVP is not an incomplete version — it is the smallest proof that someone will pay for the problem you solve

The most expensive mistake in a new product

The most common mistake when building an MVP is not technical — it is conceptual. The team reads "Minimum Viable Product" and understands "simplified version of the final product". They cut screens, cut features, keep the same mental architecture as always, just smaller. Three months later, they have a small product nobody asked for, instead of a fast answer to a question that mattered.

An MVP is not a reduced product. It is an experiment. And every experiment exists to answer a specific question — not to impress.

What an MVP actually tests

Before writing the first line of code, it is worth writing down the question the MVP will answer. Usually it is one of these three:

• Does the problem exist? Do people really feel this pain with the frequency and intensity you imagine, or is it a problem that only bothers in theory?
• Does your solution solve it? Given a concrete way to solve the problem, does people's behavior change?
• Will anyone pay for it? Even a small one, is there a real willingness to trade — money, time, attention — for the solution?

Each question calls for a different experiment, and each experiment calls for a different amount of code. Sometimes the answer fits on a landing page with a waitlist. Sometimes it fits behind a simple interface backed by a manual process, with no real automation at all. Building too much for the question you actually have is the number one reason MVPs die from scope creep before learning anything.

How to know what to cut

A practical question helps decide what stays and what goes: "if this part did not exist, could the person still perceive the value?" If yes, cut it. If no, it is the core — and the core, by itself, is already hard enough to get right.

A polished onboarding, advanced settings, personalization, multiple pricing tiers: almost all of that is decoration on a product that has not yet proven the essential part. Add it later, once the essential part is validated — never before.

Signs you validated (and signs you just built)

Validating is not "we launched and some people used it". It is different from "we built it and nobody complained". Real signs of validation:

• People come back without you having to remind them.
• Someone offers to pay before you ask.
• Users ask for more of something specific — not generic "looks good" feedback.

Signs you just built, without validating anything:

• Usage concentrated in the first few days, then silence.
• Polite, vague feedback ("cool", "interesting", "I'll try it later").
• Nobody noticed when the product went down for a day.

The first paying customer changes everything

There is a qualitative jump between "people liked it" and "someone pulled out their card". The first is opinion. The second is behavior — and behavior does not lie. A well-designed MVP is the shortest, cheapest path to that second moment. Everything before it is hypothesis; everything after it is a real product.