Blockchain makes sense when several organisations need to rely on the same record, but none should have to give another organisation unilateral control over it. That is the useful answer, without the hype.
For years, blockchain has been sold as the answer to almost every digital problem. Payments, identity, loyalty, logistics, certificates, gaming, finance: the technology was often introduced before anyone had explained the problem.
I find the opposite approach more interesting. Start with the operational friction. Then ask whether a shared, verifiable record would genuinely improve the system.
Most businesses do not need a blockchain. That is not a criticism of the technology. It is the beginning of using it intelligently.
What is blockchain actually useful for?
Blockchain is most useful for coordinating records, rights or transactions across parties with different incentives. A well-designed network can make changes visible, establish a common sequence of events and reduce dependence on a single organisation's private database.
Imagine a vehicle moving from manufacturer to transporter, dealer, fleet operator, repair network and eventual buyer. Each participant may hold a different fragment of its history. A common record can make selected events easier to verify across those boundaries.
That does not mean putting every document, identity or operational detail on a public chain. Often the useful design is a small proof on-chain, with sensitive information held securely elsewhere.
The problem is not a missing database. It is a missing agreement.
Databases are excellent at storing and updating information. If one company owns a process, controls access and can be trusted to operate the system, a conventional database is usually faster, cheaper and simpler.
The harder problem appears when several organisations must agree on what happened, who can change a record and which version should be trusted.
A shared ledger can help when no participant should quietly rewrite the history for everyone else. It creates a common reference point. But it does not remove the need for governance: participants still need rules for access, errors, disputes and accountability.
Four situations where blockchain can earn its place
1. Provenance across organisations
In supply chains, industrial assets and regulated records, the same object can pass through many hands. Recording selected milestones with verifiable timestamps can help different organisations check provenance without asking one company to be the sole source of truth.
2. Audit trails that should be tamper-evident
When the order and integrity of events matter, cryptographic proofs can make later alteration detectable. This is valuable only if the events were captured reliably in the first place.
3. Transfer of digital rights or assets
When a right needs to move between parties according to shared rules, programmable transactions may reduce reconciliation work. The legal meaning of the right must still be established outside the code.
4. Infrastructure shared by competitors
Sometimes competitors need a common technical layer without wanting one competitor to own it. A carefully governed network can offer neutral coordination. Neutrality is a governance achievement, not something a blockchain guarantees automatically.
What blockchain cannot solve
A blockchain can help prove that a record has not been silently changed. It cannot prove that the original statement was true.
If a false mileage reading, incorrect certificate or fabricated delivery event enters the system, cryptography does not magically correct it. Verification at the point of entry remains essential.
It also does not eliminate privacy obligations, commercial incentives, integration costs or the need for a responsible operator. Public permanence can be a disadvantage when data must be corrected, restricted or deleted.
This is why serious systems distinguish between the immutable evidence of an event and the editable business data around it. Corrections can be appended with a clear history; personal or confidential data can remain off-chain.
A practical test before choosing blockchain
Before building anything, I would ask five questions.
Who needs to agree?
If there is only one trusted operator, why not use its database? If several independent parties need a common reference, the case becomes stronger.
What must be verifiable?
Define the exact event, claim or transfer that needs proof. Avoid storing everything simply because the network can store something.
Who verifies the input?
Decide who is allowed to submit records, how evidence is checked and what happens when a mistake is discovered.
What belongs off-chain?
Keep personal information, large files and commercially sensitive data in systems designed for appropriate access, retention and correction. Use hashes or references only where they serve a clear purpose.
Can a simpler architecture do the job?
Compare the blockchain design with a shared database, signed records or a trusted API. The best technology is the one that solves the real coordination problem with the least unnecessary complexity.
The founder's lesson: adoption matters more than architecture
Building technology for an established industry has taught me that elegant architecture is not enough. People adopt systems when they remove work, lower risk or create value that the old process could not deliver.
A blockchain product can be technically impressive and commercially irrelevant. A simple verification step inside an existing workflow can be far more valuable than a sophisticated token model nobody asked for.
So I look less at whether a solution is decentralised and more at whether it makes trust operational: who uses it, what decision improves and why the participants will keep contributing reliable information.
Blockchain becomes interesting when users no longer need to think about blockchain. They just see a record they can verify, a transfer they can trust or a process that works across organisational boundaries.
Frequently asked questions
When should a business use blockchain instead of a database?
Consider blockchain when independent organisations need a shared, tamper-evident record and no single party should control its history. Use a conventional database when one trusted operator can manage the process more simply.
Does blockchain guarantee that data is true?
No. It can make changes to recorded data detectable, but the original input still requires trustworthy evidence, verification and accountable participants.
Does every blockchain application need a token?
No. A token is useful only when it has a clear technical or economic role. Many shared-record applications do not need a speculative or tradable asset.
Can blockchain and privacy coexist?
Yes, with careful design. Sensitive information can remain off-chain while the network stores limited proofs or references. Privacy, access control and correction procedures still require explicit governance.