Do you actually need a blockchain?
We've built on Ethereum for a decade, which is exactly why we'll tell you most blockchain pitches are database projects in disguise. Here's the test that settles it.
Every few years the question comes back around, usually tracking the crypto price. Someone senior reads about tokenisation, a vendor turns up with a deck, or a competitor announces something “blockchain-secured”, and suddenly a business that runs perfectly well on invoices and a job board is asking whether it needs a distributed ledger.
We’re allowed to be blunt about this because we’re not outsiders sneering at technology we don’t understand. Rangefront Labs has built on Ethereum for a decade, along with other chains, through at least three full hype cycles. We’ve written the smart contracts, held the keys, and watched what happened to the projects that bolted a chain on for the press release.
Blockchains solve one problem well. That problem is rarer than the pitch decks suggest, and most businesses asking the question need a database.
The one problem a blockchain solves
Strip away the jargon and a blockchain does one thing a normal database can’t: it lets several parties who don’t trust each other, and don’t want to trust a middleman, share a record they can all rely on.
Everything else in the ecosystem, the tokens, the wallets, the consensus mechanisms, exists to make that one property work without a central operator.
Which means the question “do I need a blockchain?” is really three smaller questions:
- Do multiple independent organisations need to write to this record? Not read it. Write to it. If your business is the only one adding data, you’re describing a database and paying chain prices for it.
- Is there no operator everyone already trusts? Banks, government registries, industry bodies and marketplaces are all trusted operators. If one exists and everyone’s happy to use it, the trust problem is already solved, and solved more cheaply than a chain will solve it.
- Does something of value need to move without an intermediary? Money, ownership, entitlements. If an asset has to change hands and no bank, broker or platform should sit in the middle, a chain starts to make sense.
Answer no to all three and the conversation should be over. Not because blockchain is bad, but because you’d be paying for a property you don’t need, and the price of that property is steep.
It’s worth saying what covers the gap, because “we need tamper-proof records” is usually what buyers mean when they say blockchain. Ordinary engineering already does this. An append-only audit table records every change and who made it. Cryptographic signatures prove a document hasn’t been altered since it was signed. A trusted timestamp proves when. Proper backups mean the history survives a disaster. None of it needs a token, and all of it holds up in a dispute, which is where these requirements usually come from in the first place. If a vendor jumps straight past those options to a ledger, they’re solving their sales target, not your records problem.
What the property costs you
Pitch decks are thorough about what a blockchain gives you and quiet about what it takes in return.
Immutability cuts both ways. The ledger nobody can tamper with is also the ledger you can’t quietly correct. A bug in a deployed smart contract isn’t a Friday-afternoon patch; whatever value the contract holds stays exposed while you migrate every user to a replacement. Some of the largest losses in the history of the technology were caused not by hackers breaking cryptography but by ordinary software bugs that couldn’t be fixed in place.
Keys are a new class of liability. Lose a database password and you reset it. Lose a private key and whatever it controlled is gone, permanently, with no support line to call. Now decide which staff member holds it, what happens when they leave, and how you explain all this to your insurer.
Public chains are public. Every transaction, forever, visible to competitors, journalists and anyone with a block explorer. There are ways to keep data off-chain and commit only proofs, and any competent build does exactly that, but it means most of your system is ordinary software anyway. Which raises the fair question of what the chain is still doing there.
Throughput and cost are real constraints. A well-tuned Postgres database on modest hardware will outrun a public blockchain by several orders of magnitude, for a fraction of the cost, with none of the fee volatility. If your use case involves thousands of writes a second, the chain is the bottleneck, not the backbone.
All of that is the bill for the trust property, and paying it makes sense when the property is doing work you can point to. The mistake is paying it when nobody at the table had a trust problem to begin with.
Where the answer is honestly yes
There are cases where the three questions come back yes, and they’re worth naming, because the existence of grifters doesn’t make the tool useless.
Cross-organisation provenance is the clearest one for Queensland. Agricultural exports move through growers, feedlots, processors, transporters, certifiers and overseas buyers, and no single company in that chain should own the master record. A shared ledger that each party writes to, and that an overseas customer can verify without trusting any one of them, is a legitimate fit. The hard work is still systems integration, getting each participant’s software talking to the ledger, but the ledger itself is doing a job a database can’t.
Tokenised assets are another. If ownership of something needs to be split, traded or proven without a registry operator in the middle, that’s the core use case the technology was built for. So is settlement logic enforced by code: escrow that releases when conditions are met, without either party trusting the other or paying a middleman to hold the money.
And sometimes the answer is yes because a counterparty made it yes. If a supply chain partner, marketplace or platform you need already runs on a chain, connecting to it is an integration decision, not an ideological one.
Each of these passes the three questions from earlier: several independent writers, no operator everyone is willing to trust, value moving between parties without a middleman.
How to spot the costume version
The dishonest pitch has a few reliable tells, and they’re worth knowing even if you never build anything.
A private blockchain with one operator is the big one. If a single vendor runs all the nodes, controls who can write, and can roll back the ledger, you’ve bought a slow, expensive database with a marketing department. The trust property that justified the cost isn’t there, because you’re trusting one operator, exactly as you would with a normal system.
“Your documents on the blockchain” is another. Chains are a terrible place for documents. What honest builds store is a fingerprint, a hash that proves a document existed unchanged at a point in time. Useful, occasionally. But if the pitch implies your files live on an immutable ledger, the vendor either doesn’t understand the technology or hopes you don’t.
Then there’s blockchain as fundraising costume, where a workable, boring software project gets a chain stapled on because it sounded better to investors or a grant committee. Those projects don’t fail loudly. The chain quietly becomes a liability, the team builds workarounds, and two years later someone pays to remove it.
The pattern under all three: the word is doing marketing work, not engineering work. When you hear it, ask the vendor which parties write to the ledger and why they can’t trust an operator. Watch how quickly the answer gets vague.
Ask the question before the money moves
If you’re weighing up a project where blockchain is on the table, the cheapest thing you can do is pressure-test it before anything is built. Bring the use case, the parties involved and the records they’d share. Run the three questions. If they come back no, you’ve saved a lot of money, and you probably need a custom business system with a reliable database behind it, which we’re just as happy to build.
If they come back yes, you want people who’ve been writing smart contracts since before the second hype cycle, and who’ll design for the failure modes above rather than discovering them with your money. Either way, talk to us. The answer costs nothing, and we don’t mind which one it turns out to be.
Related reading
You probably don't need AWS
AWS is the default answer, and the default quietly costs hundreds a month. Plenty of websites and business apps run happily on a free tier or a $10 server.
WordPress is more than a CMS. Treat it like a PHP framework.
Bad WordPress feels like plugin soup. Good WordPress is a PHP application runtime with an admin UI, content model and extension system already in place.
Your agency should not own your website
A tidy monthly hosting deal can turn ugly when the client does not have the code, server access, domain control or a clean exit path.
Turn the thinking into a plan.
Send the process, risk or idea. We will help you work out what is worth doing first.