I Evaluated Dozens of Blockchain Startups in 2018

In 2018, I did technical due diligence on dozens of blockchain startups seeking funding. My heuristic became simple: if you can solve the problem with a database, you don't need a blockchain. That ruled out 95% of them. What I learned changed how I evaluate every technology claim since.

This isn't an "I told you so" piece. I read the whitepapers, understood the cryptography, saw the potential. But my job was to ask: "Does this actually work better than a database?" The answer was almost always no. Understanding how something works is different from understanding whether it should be built. For my full take, see why blockchain is a solution looking for a problem and why crypto is actively harmful.

The Promise vs. The Reality

The 2017-2018 blockchain pitch was compelling:

Decentralization. No central authority controlling your data or transactions. Censorship-resistant. Trustless.

Immutability. Once something is on the blockchain, it can't be changed. Perfect audit trail. Tamper-proof records.

Smart contracts. Code that executes automatically when conditions are met. No lawyers, no escrow agents, no middlemen.

Transparency. Every transaction visible. Every state change verifiable. Trust through verification.

Each of these features is real. The problem is that most applications don't want them.

What Decentralization Actually Means

Decentralization has costs that proponents glossed over:

Performance. Every node processes every transaction. According to research from the Bank for International Settlements, Bitcoin handles about 7 transactions per second while Visa handles 65,000. The decentralization that makes blockchain trustless also makes it slow.

Consensus overhead. Getting thousands of nodes to agree on state changes is expensive - computationally, energetically, financially. That cost gets passed to users as transaction fees.

No customer service. When something goes wrong in a decentralized system, who do you call? Nobody. Lose your private key, your assets are gone forever. Send to the wrong address, there's no chargeback. Decentralization means no one is responsible. No one can help you.

Regulatory incompatibility. Decentralized systems are designed to resist authority. But most applications require legal recourse, dispute resolution, and accountability. You can't sue a smart contract.

The places where decentralization genuinely matters are edge cases for most software. Evading government control. Operating in failed states. Censorship resistance for political dissidents.

Smart Contracts Are Neither

The term "smart contract" is a marketing triumph. They're not smart. They do exactly what they're told, which is often not what was intended. And they're not contracts. They lack the flexibility, interpretation, and enforcement mechanisms that make contracts useful.

What smart contracts actually are: Programs that run on a blockchain. Code that executes when triggered. Stored procedures with a terrible programming model.

The oracle problem. Smart contracts can only access data on the blockchain. Real-world information must be fed in by "oracles." Did the package arrive? Did the candidate win? But if you trust an oracle to provide accurate data, you've reintroduced the trusted third party you were trying to eliminate.

Code is not law. The 2016 DAO hack proved this. As documented by Gemini, a smart contract bug was exploited for $60 million. The code said the exploit was allowed. The Ethereum community disagreed and rolled back the blockchain. When code and human judgment conflicted, human judgment won. That's not what smart contracts promise.

Immutable bugs. You can't patch a deployed smart contract. Bugs live forever. Every vulnerability you ship is permanent. This isn't a feature; it's terrifying for production software.

The Gas Fee Nightmare

Every Ethereum-based startup I evaluated had the same problem: users needed to pay gas fees for every transaction. Not much - maybe a dollar or two. This created insurmountable UX problems:

Users needed cryptocurrency. To use these apps, users first needed to acquire ETH. That meant creating a wallet, passing KYC at an exchange, buying crypto, transferring it. One startup showed me their onboarding funnel - 95% dropout rate at this step.

Fees varied unpredictably. Gas prices fluctuate based on network congestion. A transaction that cost $0.50 one day cost $50 the next. Users abandoned transactions when fees spiked, leaving applications in inconsistent states.

Fee abstraction was hard. Some startups tried paying fees on behalf of users. This meant running a "relayer" - a centralized service that submitted transactions. They'd reintroduced a central point of failure to make the decentralized system usable.

The fundamental problem: blockchain's costs are visible and per-transaction. Traditional systems amortize infrastructure costs into monthly fees or hide them entirely. Users don't expect to pay $2 every time they click a button.

Immutability as Bug, Not Feature

The pitch was: "Data on the blockchain can never be changed. Perfect for records that need to be permanent."

What we discovered:

Data needs to be corrected. People enter wrong information. Systems have bugs. Circumstances change. In normal systems, you fix errors. On a blockchain, you can only add corrections - the wrong data is still there forever.

Privacy regulations require deletion. GDPR's "right to be forgotten" directly conflicts with blockchain immutability. If you store personal data on a blockchain, you can't delete it. This makes blockchain fundamentally incompatible with modern privacy law.

Sensitive data exposure is permanent. If someone accidentally (or maliciously) puts sensitive information on a public blockchain, it's there forever. Every node has a copy. You can't recall it.

Most applications need mutability. User profiles get updated. Orders get canceled. Permissions change. The flexibility to modify data isn't a bug in traditional systems - it's a core feature that applications depend on.

What Blockchain Actually Does Well

After evaluating dozens of blockchain startups, I concluded blockchain has exactly one strong use case: censorship-resistant value transfer.

Bitcoin works because:

• The application (sending value) maps naturally to the technology
• Users are willing to accept the UX costs for the benefits
• Censorship resistance is the actual requirement, not a theoretical nice-to-have
• Immutability of transaction history is genuinely desirable

Everything else I saw - supply chain tracking, identity management, voting systems, healthcare records - was forcing blockchain into applications that would be better served by a database with good access controls. The NFT crash followed the same pattern: technology in search of a problem.

The Database Test

I developed a simple heuristic: If you can solve the problem with a database, you don't need a blockchain.

"But we need immutability!" Append-only databases exist. Audit logs exist. Git exists. You can have immutable records without consensus mechanisms.

"But we need transparency!" Make your database publicly readable. Publish your data. API access. Transparency doesn't require blockchain.

"But we need to eliminate trusted third parties!" Do you? Most business applications work fine with trusted parties. Banks, escrow agents, arbitrators - these exist because they provide value. The question is whether eliminating them creates more value than the blockchain overhead costs.

"But we can't trust the other parties!" If you can't trust the parties you're doing business with, blockchain doesn't fix that. They can still lie about off-chain data. They can still fail to deliver physical goods. The blockchain only guarantees what's on-chain. Almost everything that matters is off-chain.

The Hype Cycle Pattern

Watching blockchain from 2017-2018, I saw a pattern that repeats with every technology hype cycle:

Technology capability is real. Blockchain does do what it claims. The cryptography works. Decentralization is real. Smart contracts execute.

Use case fit is assumed. Because the technology is cool, people assume it solves real problems. "We have this hammer, so everything must be a nail."

Friction is dismissed. Early adopters accept friction because they're excited about the technology. They assume mass market users will too. They won't.

Existing solutions are undervalued. The problems blockchain claims to solve are often already solved, just in less exciting ways. But "boring database with good practices" doesn't raise funding.

Sunk cost sustains belief. After investing millions in blockchain solutions, teams have strong incentives to find reasons they'll work. They rarely do.

The Due Diligence Checklist

After evaluating dozens of blockchain pitches, here's what I learned to ask:

Start with the problem, not the technology. What are you actually trying to solve? Is the current solution failing? Why? Will blockchain address those specific failures?

Count the costs honestly. Performance, fees, UX friction, development complexity, operational challenges. These aren't temporary problems that will be solved "soon." They're architectural tradeoffs inherent to the technology.

Be skeptical of "trust" arguments. Most applications don't have trust problems that blockchain solves. The parties involved trust each other enough, or they have legal recourse. Trustlessness is expensive; make sure you're actually buying something.

Watch what people build, not what they pitch. The blockchain applications that work (cryptocurrency exchanges, DeFi protocols) are all about moving tokens around. That's what the technology does well. Everything else is trying to force fit.

Technology enthusiasm is not market validation. Developers getting excited about elegant cryptography is not the same as users wanting the product. These are different things.

Applying the Lessons Forward

The blockchain hype cycle wasn't unique. The same pattern plays out with every overhyped technology:

• Real capabilities get extrapolated into imaginary use cases
• Friction gets dismissed as temporary
• Existing solutions get undervalued
• Technology enthusiasm substitutes for user research

I see echoes of this in AI hype today. The technology is real. Some applications are transformative. Many proposed applications are solutions looking for problems. The question is always the same: Does this technology solve a real problem better than alternatives, accounting for all costs?

The answer is often yes for narrow applications and no for broad ones. Blockchain is great for censorship-resistant value transfer. AI is great for specific pattern recognition tasks. Neither is great for everything, despite what the pitch decks claim.

"The term "smart contract" is a marketing triumph. They're not smart. They do exactly what they're told, which is often not what was intended."