Do you actually need a blockchain?

We build blockchain systems. We also talk a meaningful share of enquirers out of building one, and it costs us the engagement often enough to be worth explaining why.

A distributed ledger is a specific tool with a specific cost: slower writes, higher operating expense, public code, and state that is effectively permanent. Those costs buy you one thing — the ability to agree on shared state without a trusted intermediary. If you do not need that, you are paying for it anyway.

The test

Answer these three honestly.

1. Do multiple organisations that do not fully trust each other need to agree on the same records?

If one company controls the data, the answer is no. An internal audit trail is not a trust problem; it is a logging problem.

2. Must assets move between parties without an intermediary?

Tokens, digital ownership, programmatic settlement. If a bank or a payment processor is in the flow anyway, the intermediary already exists.

3. Must someone outside your organisation be able to verify history independently, without trusting you?

Not "would it be nice if they could" — must they, as a condition of the system working. Regulators and auditors usually accept a well-designed database with immutable logging.

If you answered no to all three, you want a database. A properly designed append-only event log in PostgreSQL gives you an immutable audit trail, costs a fraction as much to run, is orders of magnitude faster, and — critically — can be corrected when you get something wrong.

The costs people underestimate

Permanence. Deployed contracts cannot be edited. Upgradeability must be designed in beforehand through proxy patterns, and every such mechanism adds centralisation and its own attack surface. You are trading the property you came for.

Public code. Your business logic is readable by everyone, including people looking for a way to extract value from it.

Financial bugs. In ordinary software a bug is a defect report. In a deployed contract holding value, it is a loss. This is why audits are not optional and why the engineering is slower.

Privacy is hard. Personal data must stay off-chain — only hashes, commitments or proofs go on the ledger. Writing personal data to a public chain is irreversible and conflicts directly with GDPR and DPDP erasure rights.

Key management. Losing a key loses the asset. There is no reset link. For an organisation, this is an operational problem that needs real process rather than one person with a hardware wallet.

Where it genuinely fits

Multi-party supply chain provenance. Several organisations, none controlling the others, needing a shared record no single party can alter retroactively. This is the strongest non-financial case.

Tokenised assets and programmatic settlement. Where transfer without an intermediary is the product.

Public verifiability. Where a claim must be checkable by anyone — certificate authenticity, public registries, verifiable credentials.

Decentralised finance. Where the absence of an intermediary is the point.

A middle path people miss

You often want verifiability rather than decentralisation. If so, you can keep the data in a normal database and anchor periodic Merkle roots on a public chain. Anyone can then verify that a record existed at a point in time and has not been altered, while you keep the speed, cost and correctability of ordinary infrastructure.

This gets you most of the trust benefit for a small fraction of the cost, and it is the right answer more often than either extreme.

If you are building anyway

• Get an independent audit before mainnet. Not after.
• Write invariant tests, not just unit tests. The bugs that matter are properties that should always hold.
• Decide your upgrade and pause strategy during design, and write down what it costs you in decentralisation.
• Keep personal data off-chain, permanently.
• Plan key management as an organisational process, not a person.

---

We will tell you which case you are in before you spend anything. See our blockchain services, or describe the problem and we will give you a straight answer.