The question nobody asks before the kickoff call
Most blockchain project briefs start with the technology already decided: "we need an NFT platform," "we want to tokenize this," "can you build us a DAO." Almost none of them start with the actual question that decides whether any of that is a good idea: do multiple parties who don't fully trust each other need to agree on the state of something, without a middleman?
If the answer is no, a blockchain doesn't make the product better. It makes it slower, more expensive to change, and harder to hire for — for a trust guarantee nobody in the system actually needed.
What a blockchain is actually good at
Strip away the hype and a blockchain is a specific tool for a specific job: a shared, append-only ledger that multiple independent parties can verify without relying on one of them to be honest. That's it. The three situations where that's genuinely valuable:
Multi-party trust without an intermediary. A DeFi lending protocol works because borrowers, lenders, and liquidators don't have to trust a bank — the smart contract enforces the rules the same way for everyone, and anyone can verify it did. Remove the "multiple parties, no trusted middleman" condition and you're just describing a loan ledger, which a database handles fine.
Provable scarcity and transferability. A token or NFT is useful when the scarcity and the transfer history need to be independently verifiable by people outside your organization — a collectible, a real-world asset with fractional ownership, an in-game item players expect to trade outside the game's own servers. If ownership only ever needs to be checked inside your own system, a database row does the same job for a fraction of the engineering cost.
Disintermediated governance. A DAO makes sense when a genuinely dispersed group of stakeholders needs to make binding decisions about shared funds without a single company controlling the treasury. Most "DAOs" we get asked to build are actually one company wanting the branding of decentralization while still controlling every key decision — that's a permissions system, not a DAO.
What it doesn't fix
A blockchain doesn't make bad data good — garbage in is still garbage out, just now it's permanently, publicly garbage. It doesn't make a slow system fast; even high-throughput chains are slower than a well-indexed Postgres table for anything that isn't specifically benefiting from consensus. And it doesn't add trust automatically — a smart contract with a bug is a bug that moves real money, immutably, the moment someone finds it. "It's on-chain" is not a substitute for security review; if anything, it raises the stakes of getting the review wrong.
The filter we actually use
Before recommending a blockchain build, we ask one question: would a well-run database with a public audit log solve this just as well? If the answer is yes — and for most internal tooling, most loyalty programs, most "verify this credential" use cases, it is — build the database. It's cheaper, faster to change when requirements shift, and just as trustworthy for a system where you're the only party who needs to trust the data.
The projects where the answer is genuinely no tend to share the same shape: real money moving between parties with no existing trusted intermediary (DeFi), assets that need to be verifiably scarce and freely tradable outside any one company's servers (tokenization, gaming assets with real interoperability), or governance where the whole point is that no single party controls the outcome (real DAOs, not branded permission systems).
Chain choice matters more than people assume
Once a blockchain is actually the right call, which chain matters as much as the decision to use one at all. EVM chains — Ethereum, Base, Polygon, Arbitrum — have the deepest tooling and audit ecosystem, and Solidity contracts built on OpenZeppelin's audited standards are the safest default rather than reinventing primitives from scratch. High-throughput chains like Solana or Near, built in Rust, make sense when transaction volume or fee sensitivity rules out EVM gas costs — a high-frequency trading protocol or a game with constant on-chain micro-transactions, for instance. Picking the chain based on community hype instead of your actual throughput and cost requirements is one of the more expensive mistakes we see un-done later.
Security isn't optional once real value is on-chain
Any contract handling real money needs a Foundry test suite — unit tests, fuzzing, and invariant checks — before it goes anywhere near an external audit, and an external audit before mainnet if the contract holds meaningful value. This isn't a nice-to-have layered on at the end; the cost of finding a reentrancy bug in review is a code change, and the cost of finding it after launch is a headline.
What it costs
An NFT mint or straightforward token launch starts around $10,000. A full dApp or DeFi protocol — contracts, frontend, wallet integration, on-chain indexing — starts from $35,000+, and that figure excludes external audit fees, which scale with contract complexity and are worth budgeting for separately rather than treating as an afterthought.
Bottom line
The right question isn't "should we use blockchain." It's "do multiple parties who don't trust each other need to agree on this without a middleman." If yes, our blockchain & Web3 team can scope the contracts and the app around that real requirement. If no, we'll tell you that too — a fast, boring database is a better product than a slow, expensive ledger nobody needed.
