I have been asked to build on a blockchain four times. Three of those projects would have worked better as a Postgres table with an audit log, and I said so, and two of the clients agreed. The fourth was a genuinely good fit and became one of the more interesting things I have worked on.
That ratio is roughly my honest view of this space. The technology is real and it solves a specific problem well. The problem is narrower than the marketing suggested, and most of the projects that failed between 2021 and 2024 failed because they were using a coordination tool to solve a storage problem.
So: what a blockchain actually gives you, when that is worth its cost, and what building on one is really like.
The One Thing It Does That a Database Cannot
Strip away the terminology and a blockchain is an append-only ledger replicated across parties who do not trust each other, where the rules for appending are enforced by code that all of them can verify.
That last clause is the whole product. A database also stores records; a database with an audit log also keeps history. What a database cannot do is let two competitors share one set of records without either of them controlling it, or without paying a third party to be the trusted middle.
So the question I ask before anything else: is there a trusted party available, and is anyone unhappy about trusting them?
If your company owns the data and your users are fine with that, you want a database. If a bank sits in the middle and everyone is content with the bank, you want the bank's API. Blockchain becomes interesting when the answer is that no acceptable trusted party exists — multiple organisations with competing interests who need to agree on a shared state, or a system whose credibility depends on nobody being able to quietly change the rules.
Most business problems have a trusted party. That is why most blockchain projects should not have been blockchain projects.
Smart Contracts: Programs With Unusual Constraints
A smart contract is code deployed to the chain that runs identically on every node and whose state is part of the ledger. Conceptually simple. Practically, it is programming under constraints that make ordinary engineering habits dangerous.
Deployed code is effectively permanent. There is no hotfix. Upgrade patterns exist — proxies pointing at replaceable implementations — but they add complexity and they reintroduce a privileged party who can change the rules, which was often the point of not using a database.
Every operation costs money. Storage is enormously expensive relative to computation. This drives design decisions that look bizarre from outside: keeping data off-chain and storing only a hash, packing values into single storage slots, avoiding loops over arrays that could grow.
Everything is public. Private variables are private to other contracts, not to people. Anyone can read the full state and the full history. Anything confidential lives off-chain with only a commitment on-chain.
The adversary is well funded and the bug bounty is the balance. This is the part that changes how you write code. In a web application, a bug is a support ticket. In a contract holding value, a bug is an immediate and irreversible transfer to whoever noticed first.
// Checks, Effects, Interactions — in that order, always.
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount, "insufficient"); // checks
balances[msg.sender] -= amount; // effects
(bool ok, ) = msg.sender.call{value: amount}(""); // interactions
require(ok, "transfer failed");
}
Moving that subtraction after the external call is the reentrancy bug that has drained many millions of dollars across many projects. The external call can re-enter withdraw before the balance is updated, and the check passes again. It is a two-line ordering issue with catastrophic consequences, and it is representative of the category.
What this means in practice: use audited libraries rather than writing primitives yourself, get a professional audit before holding real value, and assume that anything you deploy will be read line by line by people looking for exactly this.
Where It Has Genuinely Worked
Setting aside the speculative side of the industry, the applications I find defensible share the same shape — multiple parties, no natural trusted middle, and value in verifiability.
Cross-organisation supply chain records, where a manufacturer, a shipper and a retailer all need the same provenance data and none of them wants to host the other's records. The hard part here is not the chain; it is that data entered at the physical step can still be wrong. A blockchain guarantees the record was not altered afterwards. It cannot guarantee it was true when written.
Settlement between institutions, where reconciliation between separately-maintained ledgers is the actual expense being removed.
Verifiable credentials — proving a certificate or licence is genuine without contacting the issuer, which matters when issuers disappear or when checks must work across borders.
Systems whose credibility depends on rule immutability, where "we could change this later" would undermine the entire proposition.
The common thread: coordination between parties, not storage of data.
What Building Actually Involves
The parts that surprise engineers coming from web development.
Almost everything is off-chain. A working dApp is a normal application — frontend, backend, database, indexer — with a small amount of contract logic at the centre. You still need a server, because reading chain history directly is far too slow for a user interface. You end up running an indexer that watches events and writes them into a conventional database that your API queries. There is more Postgres in a typical Web3 project than people expect.
Finality is not instant. A transaction is submitted, sits pending, gets included, and only becomes practically irreversible after some confirmations. Your interface has to represent that honestly, and your backend has to handle a transaction that never confirms or gets reorganised out.
Fees are user-visible and variable. An action that cost a few cents last week can cost several dollars during congestion. Layer-2 networks have improved this dramatically, and it remains a product design constraint rather than an implementation detail.
Key management is the real user experience problem. Lose the key, lose everything, with no recovery. This is the single largest barrier to mainstream use, and account abstraction and social recovery are genuine improvements rather than marketing — but any consumer product still has to answer "what happens when a user loses their phone" before it answers anything else.
The Question I Would Ask First
Before writing a line of Solidity, answer this: who are the parties, and why can none of them be trusted to hold the database?
If you can name the parties and articulate the conflict, you may have a real use case and the rest is engineering. If the answer is vague — "it's more secure," "it's decentralised," "the industry is moving that way" — you are about to pay a large complexity premium for a property nobody needed.
That question is why I talked two clients out of it and helped one build something that worked. It is not scepticism about the technology. It is that a blockchain is an expensive answer to a specific question, and it is worth being sure you are asking that question before you buy the answer.
