Why Serious Web3 Development Starts With Saying “No”

Most enterprise blockchain pilots end up going nowhere. Teams that build Web3 systems with staying power are the teams that are happy to say no to blockchain, and to say exactly why.

The Graveyard of Blockchain Pilots

Enterprise blockchain follows a well-worn pattern: enthusiastic pilot, glowing press release, quiet cancellation. According to research from Gartner, around 5% of enterprise blockchain pilots ever reach production, and even those that make it still need substantial Web3 work done in two years to keep pace with the competition.

Postmortems follow a predictable pattern. The team creates a permissioned ledger to solve a coordination problem, a problem that would have been much better solved by a shared database with a signed audit log.

Or a company tokenizes something — loyalty points, tickets, credits — because it seems inevitable. But token holders don’t actually need all of the properties that only a blockchain can provide.

Or a company gets stuck trying to tokenize supply chains or medical records because both of those scenarios involve multiple parties already bound by contractual relationships, auditors, and regulators. The trust problem had been solved before the blockchain architecture even came into play.

None of this indicates failure of the underlying technology. It just means the industry wasted many years treating architecture decisions as marketing decisions.

What Saying No Really Sounds Like

Teams of good engineers don’t reject blockchain because they aren’t Web3 believers. They reject blockchain by posing a set of simple questions which don’t depend on Solidity or gas prices.

• Is trust or data sharing the problem? If all parties already trust a single operator — whether it be a bank, a hospital network, or a logistics company — an adequately engineered API can do the trick for substantially less money than a distributed ledger.
• Who will pay if there is an error? Immutability of smart contracts is one of their strengths for tamper-proof settlement and one of their weaknesses when business logic needs to be corrected.
• Does it decentralize participation or just the data? Running a private chain managed by a single company isn’t substantively different from running a regular server, except it costs more and is harder to query.

Of course, the two incidents that still come up more often than anything else in this conversation are the DAO exploit and the Ronin bridge breach. And neither of them had problems because of vulnerabilities in the contracts. On the contrary, they did precisely what they had been written to do.

In practice, teams that ask these kinds of questions in advance kill off quite a lot of proposed blockchain use cases even before they write any code, not because of a flaw in the technology but because the traditional backend does the job.

Where Web3 Discovery Really Takes Place

That’s when the team earns its stripes as a technical partner. Teams offering web3 development as one of many services as opposed to being exclusively web3 developers typically begin with a discovery phase.

It includes understanding of trust assumptions, the anticipated transaction volume, regulatory compliance, and a plan for a hard fork of the chain if that becomes necessary. After that comes a proposal for contract architecture. Occasionally, it includes a suggestion to avoid using blockchain.

That sequence is worth more than any single technical decision. A team whose business is selling blockchain development will find ways to justify the need for blockchain development. A team that builds on different stacks doesn’t have that kind of incentive, so its recommendations carry more weight.

The Cost of Saying Yes Too Quickly

An audit of smart contracts regularly costs tens of thousands of dollars and takes weeks. Every third-party module that the contract relies upon, whether it be an oracle, a bridge, a token standard, etc., expands the attack surface.

A vulnerability that could be fixed in a day in a regular web application requires a governance vote, a token migration, or a public announcement that the funds are frozen. None of that is a reason to avoid blockchain development altogether.

But it is a good reason to approach “should it be on-chain” as a Web3 engineering question with financial consequences, not as a checklist item. And teams that have developed production smart contracts know about that price all too well because they paid for the audit, waited for it, and saw the launch date slip because of it.

Maintenance is not just a concern of the pre-launch period. Each upgrade of a contract-based system involves another round of auditing, and each integration raises the question of possible security issues. A conventional backend can survive a rushed patch. A live contract can’t.

A Simple Web3 Framework

Three questions tend to cut through the noise before adding a blockchain component to the project:

1. Is it a problem of trust? Does a signed log from a trusted operator solve it, or do participants need to verify state without trusting anyone?
2. Coordination cost. Is the cost of consensus, gas, and validator infrastructure less than the coordination problem it’s supposed to solve?
3. Is it reversible? How much is the correction of the logic on day one going to cost, and who will pay for that?

And if the answer is that the problem can be solved by a conventional database with strict access controls, that’s not an engineering failure. This is an adequate solution.

The Conclusion

The blockchain industry was rewarding teams for saying yes for too many years. The next phase of that industry will reward teams who are able to say no and back it up with a viable alternative.

That is less sexy than launching a token. But it is the kind of narrative that guarantees that the client’s system will be up and running for many years ahead.