A Web3 MVP is the smallest working version of a product that lets one real user complete the single action the product exists for, with every on-chain interaction handled safely enough that a mistake does not cost them anything.

Why the Web3 version is different

A normal MVP can be rough because mistakes are cheap and reversible. Four properties of Web3 break that assumption.

  • Actions are irreversible. A transfer or approval cannot be rolled back, so the failure path has to exist in version one rather than in version two.
  • The wallet is the identity. There is no password reset and no support ticket that fixes a wrong address. Onboarding has to be designed rather than assumed.
  • Every action costs money. Users pay for their own writes. A product that quietly wastes fees is a product people stop using.
  • State is public. Anything you put on-chain is visible to everyone permanently, which is a product decision as much as a technical one.

None of that means a Web3 MVP should be bigger. It means the definition of "smallest working" has to include the failure behaviour, because the failure behaviour is what users remember.

What belongs in version one

  • One user, one situation, one action they complete.
  • The core workflow, working end to end.
  • Visible states: loading, pending, failed, done.
  • Error messages a non-technical person can understand.
  • A visible record of what happened and what it cost.
  • A written list of what is deliberately missing.

What does not belong in version one

Second and third chains. Accounts, roles, and team permissions. Analytics dashboards. Token mechanics. Settings screens with more than three options. Any feature that only makes sense once you have users, which is most of them.

The order in which to cut these, and the reasoning behind it, is in how to scope a Web3 MVP before spending money. The short version is that each one adds a data shape, a failure mode, or a legal cost without making the core action any easier.

The four decisions that set the size of the build

Scope in a Web3 MVP is not decided by the feature list. It is decided by four things, and each one can double the work without making the product any more useful to the person using it.

  1. How many chains. Every additional chain is a second data shape, a second wallet flow, a second set of failure messages, and a second provider to pay. Ship one until a real user asks for the second.
  2. Whether money moves. Reading chain state is a display problem. Moving value is a custody, accounting, and irreversibility problem, and it changes what testing means.
  3. Who owns the failure path. When a transaction fails halfway, does the product tell the user something true and offer a next step, or does it go quiet? Answering that properly is a feature, not polish.
  4. How much discovery is already done. A written direction removes the expensive part of a build, which is deciding what to build. Without one, the first week of engineering becomes a discovery sprint nobody scoped or paid for.

A worked example of cutting scope

Valor started as a general community assistant and became one bounded action: score a message, pay the contributor. The general version had more features and no defensible failure boundary. The narrow version can be described in a single sentence, which means its failure modes can be listed in a single paragraph, which means they can actually be tested.

Spellbook went the other way. It is a marketplace with checkout, provisioning, and handover, and the scope is large on purpose because the workflow is the product. That is a legitimate larger build. The point is that its size was chosen rather than accumulated, and the difference shows up in how precisely each project can state what it does not do.

How you know it worked

A person who was not in the room completes the action without being walked through it. You can see that it happened. You know what is unproven, because it is written down. And the next version has an obvious starting point, because the limitations list became the backlog.

If that standard sounds narrow, it is meant to be. The focused product build exists to hit exactly that and nothing wider, because every attempt I have seen to widen it early has cost more time without producing more learning.