We build blockchain systems. We also talk clients out of them more often than we build them. The most useful thing we can tell you about this technology is when you don’t need it.
A blockchain is a database that trades away speed, simplicity, and cost in exchange for one thing: the ability for parties who do not trust each other to agree on a shared record without a middleman. If you do not need that specific trade, an ordinary database will serve you better on every axis that matters. It is faster, cheaper, easier to change, and easier to hire for.
So the real question is never “should we use a blockchain?” It is “do we have the problem that a blockchain solves?”
The problem a blockchain actually solves
Picture several organizations that need to share one set of records: a shipment’s history, say, as it passes between a manufacturer, a shipper, a customs broker, and a buyer. None of them fully trusts the others to hold the master copy. Nobody wants to pay a central operator to sit in the middle and rule on disputes. Everyone needs to be certain the record has not been quietly edited after the fact.
That is the shape of a genuine blockchain problem: multiple parties, limited trust, no natural intermediary, and a strong need for a shared record that no single participant can rewrite. When those conditions hold, a blockchain earns its complexity. It gives every party the same tamper-evident history and removes the argument about whose copy is correct.
Value transfer is a version of the same story. Moving money or assets between parties without a bank or a clearing house in the middle is exactly the case these systems were built for.
When it is the wrong answer
Most business problems do not look like that. They look like this:
- One organization owns the data. If you control the records and your customers trust you to, you do not need a consensus mechanism. You need a good database and good backups.
- The data is private. Public blockchains are, by design, visible and permanent. Putting personal or confidential data on one is a liability. Even private chains carry rules about immutability that fight against privacy laws like the right to erasure.
- You need speed and low cost. On-chain operations are slower and more expensive than a normal database write, sometimes by a wide margin. If your product depends on high throughput or thin margins, that tax is hard to justify.
- The data needs to change. Smart contracts are difficult to alter once deployed. That permanence is a feature when you want an unbreakable rule, and a curse when you find a bug or a requirement shifts.
If any of these describe your project, a blockchain is usually the wrong tool. Reaching for it anyway tends to mean months of extra work, a smaller pool of engineers who can maintain it, and a system that is harder to explain to your own team.
The questions to ask first
Before anyone writes a smart contract, we work through a short list:
- Who are the parties, and do they trust each other? If there is one party, or full trust, stop here.
- Is there a natural intermediary you are trying to remove, and is removing it worth the cost?
- Does the record need to be tamper-evident to people outside your own organization?
- What data goes on-chain, and can it legally and safely live somewhere permanent and visible?
- What happens when you need to fix or change it?
The answers usually settle the matter in an afternoon. Often the conclusion is that a conventional system, with a clear audit log, does everything the client actually needs, without the tax.
When it is right, do it properly
When a project does clear the bar, the discipline shifts. On-chain code is adversarial software: it holds value, it is public, and it is hard to change. That means treating security as the main event from the first line of code. It means writing tests alongside the contracts, documenting how upgrades and pauses will work before launch, and building so an external audit confirms your work rather than rescues it.
A firm that will happily sell you a blockchain for every problem is not one to trust with the problems that genuinely need it.
The short version
Blockchain is a specialized tool with a narrow, real purpose: shared truth among parties who do not trust each other. Used there, it earns its keep. Used anywhere else, it is a costly way to build something a database already does well. Ask what problem you have before you choose the tool.