Most briefs that ask for blockchain do not need one

We turn down blockchain work fairly regularly, and almost always for the same reason: the brief describes a database.

That is not a criticism of the person who wrote it. The pitch for blockchain — tamper-evident, shared, auditable — describes properties every serious system wants. The question is what you are paying for them with.

The question that actually decides it

Not throughput. Not cost. Not whether the industry is moving that way.

Does someone who does not trust you need to verify the record without asking you?

If the answer is no, you want a well-designed database with an append-only audit table, proper access control and backups you have actually restored from. It will be faster, cheaper, easier to hire for, and you can fix a mistake in it.

If the answer is yes — genuinely yes, with a named party who has a real reason to distrust the operator — then you are in the small set of problems where a chain earns its cost. That set is real. It is much smaller than the set of briefs that ask for it.

Three briefs that fail the test

“We want an immutable audit log.” An append-only table with restricted write access and off-site backups gives you this. Immutability against your own administrators is a permissions and infrastructure problem, and solving it with a distributed ledger is an expensive way to express a policy you could enforce directly.

“Our supply chain partners need shared visibility.” Shared visibility is an API and a permissions model. The chain only becomes relevant when partners need to verify each other’s entries without a central operator vouching for them — and in most supply chains there is a central operator everyone already trusts, which is usually the largest buyer.

“We want to tokenise the asset.” Sometimes correct. Worth asking what the token does that a database row and a contract cannot, and who is expected to hold it. If the answer is that it makes fundraising easier, that is a real reason, but it is a financing decision rather than an architecture one and should be argued on those terms.

What passes

Records several parties write to, where the parties have a commercial reason to dispute each other’s entries and no single one of them should be able to rewrite history. Assets that need to move between systems that do not trust each other. Anything where the audit is the product, and the auditor is external.

The honest tell: if removing the chain and replacing it with a database run by the most trusted participant would be fine with everyone, that is your answer.

The costs nobody puts in the brief

A mistake is permanent. Software has bugs, and the usual remedy — fix it and correct the data — is not available in the same way. That changes how much testing is proportionate, and the budget rarely reflects it.

Key management becomes your problem, and it is a harder problem than it sounds. A lost key is a lost asset, with no reset flow. Designing custody for people who are not crypto-native is a real part of the work and is almost never scoped.

And on-chain data is public, which cuts against most compliance postures unless the design keeps personal data off the chain from the first day. Retrofitting that is not a refactor.

Where this leaves the decision

The useful version of the conversation is short. Name the party who must verify without trusting you. If you cannot name them, build the database — you will ship sooner and the audit properties you actually wanted are available there.

If you can name them, the chain is doing real work, and the design questions become interesting: what goes on-chain versus off, who holds keys, what happens when a participant leaves.

We build both. The Web3 dapps demo shows the shape of the second case, and custom blockchain development covers where it goes from there. If the comparison itself is what you are weighing, we wrote it up directly: blockchain vs a traditional database.