A real MVP: how to close the scope of version one

"MVP" has been repeated so often that it has lost its meaning. Many teams read it as "the cheap, incomplete version" and end up with a product that does nothing properly.

An MVP is the smallest version that solves one real problem end to end. Small, not incomplete.

Small versus incomplete

Say you are building an ordering system. The incomplete version lets users browse and add to a cart, with payment "coming later". That delivers no value at all.

The small version sells one product category, with one payment method, no discount codes and no accounts — but an order really is placed and paid for. The path is complete; it is just narrow.

Four questions for every feature

1. Does the main journey break without it? If not, it isn't in v1.
2. Can it be done manually? Plenty of work can be handled behind the scenes at first, until you know it is needed.
3. What do we fail to learn if we drop it? Version one exists to learn. A feature that teaches nothing can wait.
4. Is it expensive to add later? This is the only good reason to include something you don't need today.

Write the "out of scope" list

The most important part of defining an MVP is the list of things that will not be built. It has to be written and approved; otherwise every meeting adds a feature.

When someone says "let's add this too", the answer isn't "no". It is "I'll put it on the v2 list." The idea survives and the scope stays intact.

Build small, think big

This is where MVP and architecture meet. A small first version must not be a technical dead end. If v1 has to be rewritten for v2, you haven't saved anything — you have only postponed the cost.

The answer is to draw the boundaries correctly from day one and put the simplest implementation behind each of them. Payment sits behind a defined layer: one gateway today, several tomorrow, without touching the rest. I unpack this in final architecture from day one, a lean implementation to start.

Keeping scope creep in check

• Every scope change is a written decision. If something is added, state what is dropped or how far the date moves.
• Keep the success metric visible. A feature that doesn't serve it has no priority.
• Show version one early. Real feedback beats hypothetical debate.

An example from real work

In Pasokhinoo, the core value was an AI agent that answers from a store's real catalogue and completes the purchase inside the same chat. That is the test that shapes scope: whatever completes that path comes first, and whatever is merely interesting waits.

The takeaway

A good MVP solves one problem completely, has a written "out of scope" list, and sits on an architecture that allows growth. With those three, version one ships early and isn't thrown away.

To turn an idea into a defined scope, the PRD is the next step.