The Decision Tree
Before evaluating blockchain platforms, ask these questions in order. If any answer is “no,” you probably do not need a blockchain.
Blockchain Decision Tree:
Do multiple organizations need to share data?
├── NO ──► Use a traditional database. Full stop.
│
YES
│
Do these organizations distrust each other or lack a
trusted intermediary?
├── NO ──► Use a shared database with access controls.
│ A cloud database with proper IAM is simpler.
│
YES
│
Is the cost of disputes, fraud, or reconciliation
significant enough to justify the infrastructure?
├── NO ──► The problem exists but blockchain is over-
│ engineered for the cost involved. Use existing
│ reconciliation processes.
│
YES
│
Do you need tamper-evident records specifically?
├── NO ──► Consider message queues, API integrations,
│ or traditional EDI. Not every sharing problem
│ needs immutability.
│
YES
│
Can all parties agree on governance, data standards,
and operational procedures?
├── NO ──► Fix governance first. Blockchain cannot solve
│ organizational disagreements. If parties cannot
│ agree on data schemas, they won't agree on
│ smart contract logic either.
│
YES ──► Blockchain may be appropriate. Proceed with
architecture evaluation.Scenario 1: Single Organization Data
If your organization is the only one writing and reading the data, a blockchain adds complexity without adding value. You control all the nodes. You control the consensus. The immutability guarantee is only as strong as your own willingness to maintain it, which means it is no stronger than the access controls on a traditional database.
I have seen companies build “internal blockchains” for audit trails that a properly configured PostgreSQL database with append-only tables and cryptographic hashing could handle at a fraction of the complexity. The blockchain label made the project sound innovative, but the architecture was objectively worse than the simpler alternative.
Scenario 2: Trusted Intermediary Exists
If there is already a trusted party that all participants accept as the operator of shared data, you do not need distributed consensus. Credit card networks work because all merchants trust Visa and Mastercard as intermediaries. Stock exchanges work because all traders trust the exchange as the central counterparty. Adding a blockchain to these scenarios replaces a functioning trust model with a more complex one for no clear benefit.
The Australian Securities Exchange (ASX) attempted to replace its CHESS clearing system with a blockchain-based alternative. After seven years and over $250 million in investment, they abandoned the project in 2022. The existing centralized system worked. Participants trusted the ASX as operator. The blockchain added complexity without solving a trust problem that actually existed.
Scenario 3: Low-Value Transactions
Blockchain infrastructure has fixed costs, nodes, development, governance, auditing. If the transactions flowing through the system are individually low-value and the dispute rate is low, the cost of the blockchain infrastructure may exceed the cost of just handling disputes when they arise.
A coffee shop loyalty program does not need a blockchain. The dispute rate is near zero. The transaction values are trivial. The cost of a customer complaining about a missing stamp is negligible compared to the cost of maintaining a distributed ledger for stamp tracking.
Scenario 4: Data Needs to Be Mutable
Some data legitimately needs to be updated or deleted. Patient medical records need correction when errors are discovered. Customer data needs deletion under GDPR. Product catalogs need price updates. If your primary data needs to be mutable, an immutable ledger is fighting your requirements rather than serving them.
Yes, you can build append-only correction patterns on blockchain. But if the majority of your operations involve updating existing records, you are using the wrong data structure. The overhead of creating correction transactions for routine updates is a sign that a traditional database would serve you better.
Scenario 5: Performance Requirements Exceed Blockchain Capabilities
High-frequency trading systems process millions of transactions per second with microsecond latency. Real-time gaming backends need sub-millisecond response times. Streaming analytics platforms process millions of events per second. No blockchain, public or private, comes close to these performance requirements. If your use case demands extreme throughput or ultra-low latency, blockchain is architecturally inappropriate.
The Honest Checklist
Before committing to a blockchain project, honestly answer these questions:
- Can we name the specific multi-party trust problem we are solving?
- Have we quantified the cost of the current problem (disputes, reconciliation, fraud)?
- Is that cost larger than the projected blockchain infrastructure cost?
- Have we evaluated whether a simpler shared database with proper access controls could solve the same problem?
- Do we have committed participants who will actually use the system?
- Can we agree on data standards and governance before building?
If you cannot answer yes to all of these, you are likely building a blockchain project because the technology is interesting rather than because the problem demands it. That is a valid reason for a research project. It is a terrible reason for a production deployment.