A Founder's Framework for Deciding Whether Blockchain Belongs in the Product

We are asked some version of this monthly, usually by a team that has already half-decided. The framework below is what we actually use, and it is deliberately hostile — most products should fail it.

1. Is there a trust problem between parties who do not trust each other?

Not 'would users like transparency'. Is there a specific coordination or verification problem between parties with divergent interests, where no single operator is acceptable to all of them? If a trusted operator exists and is acceptable, a database is better in every dimension that matters.

2. Does ownership need to move without an intermediary?

Transferability where the transfer must be final, verifiable and not dependent on an operator remaining solvent or cooperative. This is the strongest case for the technology and the least frequently the real requirement.

3. Does settlement need to be atomic across parties?

Where an exchange must either complete entirely or not at all, across systems no single party controls. Genuine, and genuinely rare outside financial infrastructure.

4. Does the record need to outlive the company?

If the answer is yes — if a holder's position must remain verifiable after the issuer is gone — that is a real requirement that a hosted database does not meet. It is also a commitment most teams have not thought through.

What a no to all four means

That the technology is being used for positioning rather than function, which is a decision with costs: engineering complexity, regulatory surface, a narrower hiring pool and a harder enterprise sale. Occasionally worth paying. Rarely worth paying accidentally.

The teams we back in this area answered yes to at least one, specifically, and could say which.