Do you actually need a blockchain?

Probably not. A blockchain earns its cost when multiple parties who do not trust one another must agree on a shared record without a central authority, or when an asset must be transferable without anyone's permission. If one organisation controls the data, a database is faster, cheaper, easier to fix and far easier to comply with.

We build smart contracts in Solidity, Rust and Move. We say this anyway, because the alternative is taking a budget to build something that will be quietly replaced with a database in two years.

The three questions

1. Who writes to the record, and do they trust each other?

If the answer is "us, and our own staff", stop here. You want a database with good access control and an audit log. Decentralised consensus solves a trust problem you do not have, and you would be paying for it in latency, cost and operational complexity on every single transaction.

The test is genuinely about adversarial parties. Two competing banks settling between themselves, an open marketplace where anyone can list, a consortium where no member will accept another running the server — those are real cases.

2. Would anything break if you could edit the record?

Immutability is the property people ask for and rarely need. Most businesses want an audit trail, which a database provides perfectly well: append-only tables, signed entries, off-site backups. The difference is that a database's history can be corrected by its owner — which is usually a feature, because real data has real mistakes in it.

Ask what specifically goes wrong if you retain that ability. If the answer is "nothing, we just like the idea", you want an audit log.

3. Does the asset need to move without permission?

This is the strongest genuine case. A token that anyone can hold and transfer without an intermediary approving it is something a database fundamentally cannot be. If permissionless transfer is core to the product, you need a chain.

If transfers happen inside your system between accounts you control, that is a ledger table.

When the answer is yes

Then the engineering standard is different from ordinary software, and this is where budgets get underestimated. Deployed contract code is effectively permanent and holds value directly, so a defect is not a bug report — it is a loss, and often an unrecoverable one.

That means:

• Code written for review from the first line, not refactored for it later
• Test suites that attack the contract rather than confirm the happy path
• An independent third-party audit before anything holds real value
• A plan for the upgrade path, decided before deployment rather than after

On that third point: treat any firm offering to audit its own contracts as a warning. We prepare the codebase and documentation for an external audit and work through remediation, but we do not sign off our own work as audited. Nobody should.

The cost nobody mentions

Chain infrastructure is not a one-off. Nodes need running and monitoring, RPC endpoints need capacity, gas costs move with network conditions, and the toolchain moves fast enough that a contract written today will be built with deprecated libraries within eighteen months. Budget for operations, not just for the build.

What we usually recommend instead

For most enquiries that arrive asking for blockchain, the honest answer is one of:

• A database with an append-only audit table and signed records
• A conventional application with a clear, published data-integrity policy
• A hybrid: ordinary infrastructure for the product, with only the genuinely trustless part — usually settlement or ownership — on a chain

That last pattern is the one that survives. It puts the expensive property exactly where it is needed and nowhere else.

If you have a token or protocol design that genuinely needs implementing, we will build it properly. And if you have a business problem that does not, we would rather tell you that in the first conversation than in the third invoice.