Does Your Business Need a Blockchain? A Decision Guide

A vendor pitches a blockchain platform. A board member asks why you aren’t “doing something with blockchain.” A partner suggests putting your shared records on a ledger. Before you spend a dollar, you need a fast way to tell whether the technology fits the problem.

The honest answer for most businesses is no. NIST’s blockchain overview put it bluntly: many organizations start with “we want to use blockchain somewhere,” which leads to frustration because the technology can’t be applied universally. The better approach is to start with the problem and see whether it has the specific shape blockchain solves.

This guide gives you a 6-question decision flow, a comparison of the alternatives and a checklist for vendor pitches.

What a blockchain actually gives you

A blockchain is a shared ledger copied across multiple computers, where participants agree on new entries through a consensus process and past entries are very hard to change without detection. Strip away the hype and you get 3 core properties:

• Shared writing without a single owner. Several parties can add records, and no one party controls the database.
• Tamper evidence. Changes to past entries are easy to detect.
• Common history. Everyone sees the same sequence of transactions, which reduces reconciliation between organizations.

Everything else, including speed, privacy, cost and ease of change, is usually worse than a conventional database. NIST notes that a blockchain only supports “create” and “read,” not the update and delete operations most business applications rely on. You can add a new entry that supersedes an old one, but the original stays in the ledger.

So the question isn’t “is blockchain good?” It’s “is the lack of a trusted central operator the main problem I need to solve?”

The decision flow: 6 yes-or-no questions

Work through these in order. A “no” at any point usually means you don’t need a blockchain.

Question 1. Do you need to store shared records or transactions? If you’re just processing data or running calculations, no ledger is needed. Answer no: you don’t need a blockchain. Answer yes: go to question 2.

Question 2. Do multiple organizations need to write to those records? If only your company writes the data and others just read it, you control the truth already. Answer no: use a regular database, with read access or an API for partners. Answer yes: go to question 3.

Question 3. Could one trusted party run the database for everyone? That trusted party might be you, an industry association, a regulator, a cloud provider or a neutral software vendor. If everyone would accept it, a central shared database is simpler. Answer yes: use a shared database with access controls and audit logs. Answer no: go to question 4.

Question 4. Do the writers distrust each other enough that they’d dispute the records? If partners already cooperate and rarely disagree, a shared database with signed entries and audit logs usually does the job. Answer no: use a shared database. Answer yes: go to question 5.

Question 5. Can the data live on a ledger that every participant copies? Personal data, health information and trade secrets may not be appropriate even on a permissioned ledger, and data that must be deleted on request is a poor fit. Answer no: keep the data off-chain and consider recording only hashes, or use a database. Answer yes: go to question 6.

Question 6. Do you need anyone in the public to verify the records, without permission? Answer yes: a public, permissionless blockchain, or a public one with controlled writers, may fit. Answer no: a permissioned blockchain run by known participants may fit.

Key takeaway: If one party you all trust could run the database, you don’t need a blockchain. A blockchain earns its cost only when several parties must write to shared records and none of them will let another be in charge.

This logic follows the same pattern as published decision tools, including the Department of Homeland Security Science and Technology Directorate flowchart that NIST reproduced and the “Do you need a Blockchain?” paper by ETH Zurich researchers Karl Wüst and Arthur Gervais. NIST observed that in that paper’s flowchart, most paths lead to “no.”

When a shared database is the better answer

Most real-world needs that get pitched as blockchain projects fall into 1 of these patterns, and each has a simpler fix:

Cloud providers also offer managed ledger databases and immutable storage options that give you tamper-evident history inside a single organization’s control. That covers many “we need an audit trail” requests.

When a blockchain might be the right fit

There are real cases where the answer is yes:

• Industry consortiums where competitors share records but won’t let one rival host the database, such as trade finance or some supply chain traceability networks
• Digital assets and payments, including stablecoins and tokenized real-world assets, where ownership must move between parties without a central registry
• Public verifiability, where anyone needs to check records without trusting a single company
• Cross-border settlement among institutions with no shared operator

NIST also lists features that suggest a blockchain may help, including many and distributed participants, a need to reduce manual reconciliation and disputes, and a need for full transaction history shared among participants.

Costs and trade-offs to weigh

Even when blockchain fits, it brings costs a database doesn’t:

• Governance. Who can join, who pays, who upgrades the software and how disputes are resolved must be agreed by all members.
• Performance. Consensus adds delay. Many permissionless networks confirm blocks in seconds or minutes, not milliseconds.
• Privacy. Data is copied to every participant, which can clash with privacy laws and confidentiality agreements.
• Bad data. A ledger proves entries haven’t changed, not that they were true when entered. NIST flags fake data input as a key consideration.
• Key management. Losing control of signing keys can mean losing control of records or assets. Our guide to hot wallets vs cold wallets explains the basics.
• Network risk. If partners leave, the network loses its value.

Big projects have stalled on these issues. Maersk and IBM shut down the TradeLens shipping platform after announcing in November 2022 that it hadn’t reached commercial viability. The Australian Securities Exchange paused its distributed-ledger replacement for its CHESS settlement system in November 2022 after an independent review found significant challenges with the solution design, and wrote off between A$245 million and A$255 million before tax.

Questions to ask a blockchain vendor

Use this checklist when someone pitches you a blockchain solution:

• [ ] Which specific problem does this solve that a shared database can’t?
• [ ] Who are the other participants, and have they committed?
• [ ] Who governs the network and pays for it?
• [ ] What data goes on-chain, and is any of it personal or confidential?
• [ ] How are mistakes corrected?
• [ ] How do we export our data if the network shuts down?
• [ ] What are the total costs, including integration, nodes and support?
• [ ] Can you show a production deployment, not just a pilot?

If the vendor can’t answer the first question clearly, stop there.

Where to start: a 5-step plan

1. Write the problem in 1 sentence, without the word “blockchain.”
2. Run the 6-question decision flow with IT, legal and the business owner in the room.
3. Price the simplest alternative first, usually a shared database, API or audit log.
4. If blockchain still wins, pilot narrowly with 2 or 3 committed partners, 1 workflow and clear success measures.
5. Agree governance before code, including membership, costs, data rules and exit terms.

If you’re exploring emerging technology more broadly, compare this decision with others on your list. Many businesses get more value from AI agents or better data infrastructure than from a ledger.

The bottom line

Your business probably doesn’t need a blockchain. You might need one if multiple organizations must write to the same records, none will let another run the database and everyone needs tamper-evident shared history. In every other case, a database, API or audit log does the job faster and cheaper. Start with the problem, run the 6 questions honestly and let the answer, not the hype, decide.

Sources

• NIST IR 8202: Blockchain Technology Overview — application considerations, DHS flowchart, create-and-read-only data, fake data input and other trade-offs
• IACR ePrint 2017/375: Do you need a Blockchain? (Wüst and Gervais) — methodology comparing permissionless, permissioned and central databases
• Parliament of Australia: The ASX CHESS Replacement Project, background — project pause and background