I Built 10 Web3 Products. Here's What I'd Delete.
ShareI Built 10 Web3 Products. Here's What I'd Delete.
Somewhere around product number six, I started keeping a running document called regrets.md.
Not in a self-flagellating way. More like: when you're deep in a codebase and you realize you made a wrong call three months ago and everything since has been compensating for it — that thought deserves to be captured somewhere. So I started writing them down.
This post is that document, cleaned up. Ten products, the real mistakes, and what I'd change. I'm not going to be vague about it.
A Quick Map of What We're Talking About
For context, here's the sequence:
- PredictX — decentralized prediction market, custom oracle resolution
- Resolutions — onchain goal commitment with staked accountability
- PressProtocol — censorship-resistant publishing (IPFS + Tor + crypto identity)
- CoreRealm — blockchain gaming with AI-driven NPCs on CoreDAO
- Terminal Portfolio — portfolio as a working shell emulator
- NFTsea — cross-chain NFT marketplace on Espresso shared sequencer
- AgenticIdentity — ML-based onchain reputation scoring with World ID
- SonicAgentHub — AI agent coordination layer for Sonic blockchain
- NebulaID — ZK identity infrastructure for autonomous agents
- UACP — agent-to-agent communication protocol with payment semantics
Roughly eighteen months, compressed. Here's what I'd undo.
Regret 1: I Built PredictX Before I Understood Oracle Risk
PredictX was a decentralized prediction market. You'd bet on outcomes, custom oracles would resolve them, fees distributed. Classic design. I was proud of the order book implementation.
The part I didn't think through: oracle resolution is the entire product. The smart contracts, the UI, the matching engine — all of that is plumbing. The hard problem is "who decides when an event has occurred and in what direction" and what happens when that decision is wrong or delayed.
I built a multi-sig oracle (three keyholders, two-of-three to resolve). Seemed secure. The problem I didn't anticipate: what happens when the event outcome is ambiguous? A prediction market on "Will Team X win the championship?" is easy. A market on "Will Protocol Y reach $1B TVL by Q3?" requires interpretation. Our three oracles disagreed on one resolution. We eventually resolved it, but the latency was five days. Five days where user funds were locked and everyone was angry.
The lesson: oracle design is contract design. Spend as much time on your resolution logic as on your matching logic. Build in arbitration mechanisms before you need them. And maybe don't start with markets that require human interpretation — start with markets that have binary, verifiable outcomes.
Regret 2: Resolutions Needed Social Mechanics I Didn't Build
Resolutions was my favorite product conceptually. You stake crypto on a goal. If you achieve it, you get your stake back. If you don't, the stake goes somewhere else (charity, a slash pool, your accountability buddy). Skin in the game for self-improvement.
The problem was the verification layer. Smart contracts can't verify whether you went to the gym three times a week. Someone has to. I built a social verification model: your designated accountability partner confirms or disputes your completion, and disputed cases go to a small jury drawn randomly from token holders.
This worked technically. It never worked socially. The accountability partners didn't take it seriously — they'd confirm whatever their friend said to avoid conflict. The jury pool was small, so the same people kept getting selected and burned out. What I'd built was a coordination mechanism without the coordination incentives.
The right design would have treated verification as a first-class economic problem. What's the incentive to be an honest verifier? In Resolutions, verifiers got nothing. They were doing it as a favor. That's not a system — that's a social obligation with extra steps.
I'd rebuild Resolutions with a proper verification market: verifiers stake to attest, slashed for dishonest attestations, rewarded for correct ones. More complex. But it would actually work.
Regret 3: CoreRealm Was a Solution Looking for a Problem
This one is uncomfortable to admit because I spent a lot of time on CoreRealm.
The pitch: AI-driven NPCs on CoreDAO blockchain, automated tournaments, stream viewer interaction with on-chain rewards. It sounds differentiated. In practice, I was solving a problem that most blockchain gamers don't have.
Blockchain gamers in 2024 cared about asset ownership and trading, not about whether the NPCs in their game had on-chain memory. The AI integration was genuinely technically interesting — storing NPC decision trees on-chain, having agents that could read game state and adapt — but it solved for a user need that didn't exist at scale yet.
I shipped it. People tried it. The feedback was consistently: "Cool, but why is this on a blockchain?" That's the death question for any Web3 product. If you can't answer it in one sentence that a non-Web3 person finds compelling, you probably haven't found product-market fit.
For CoreRealm, the honest answer was: "Because it's technically interesting to do." That's a fine reason to build something. It's not a sufficient reason to spend three months on it.
The rule I extracted: Every Web3 product needs a one-sentence answer to "why not just use a regular database?" that's better than "decentralization" or "it's on-chain." If the answer is about user ownership of assets, or about trustless settlement between parties who don't know each other, or about censorship resistance for content that would get taken down elsewhere — those are real. "AI NPCs with on-chain memory" wasn't real enough.
Regret 4: I Underestimated the Liquidity Cold Start in NexusFi
NexusFi was a staking and restaking protocol on Nibiru Chain. I was Cofounder and CTO. We designed a good protocol — liquid staking mechanics, restaking vaults, on-chain validator scoring. The architecture was solid.
The liquidity cold-start problem ate us alive anyway.
Here's the dynamic: users want to stake because yield is good. Yield is good because TVL is high. TVL is high because users are staking. That's the circle. To break into it, you need either a large initial liquidity commitment, an aggressive incentive program, or a partnership with an existing protocol that directs liquidity your way.
We had none of the three at launch. We had a working protocol and marketing. The protocol sat at low TVL for weeks, which meant low yield, which meant the early stakers who came in saw worse returns than the protocol was capable of delivering. They left. Which made the TVL problem worse.
I've seen this exact dynamic kill good DeFi protocols repeatedly since. The mistake is treating it as a marketing problem when it's actually an economic design problem. The first cohort of stakers should have outsized economics — higher APY, governance power, something — that compensates them for taking on the cold-start risk. We didn't design for that. We just launched and hoped organic growth would come.
Regret 5: PressProtocol's Threat Model Was Academic
PressProtocol combined IPFS storage, Tor anonymity, and cryptographic identity for censorship-resistant publishing. The architecture was actually quite sophisticated. IPFS for content addressing (content can't be deleted if it's pinned across enough nodes), Tor for anonymizing the publishing action itself, and crypto keys for authorship verification without identity disclosure.
The gap was that I built it for a threat model that most potential users don't face.
The whistleblowers and journalists who actually face the threat model PressProtocol was designed for — where a state actor might try to de-anonymize them — won't trust a new, unaudited protocol from an unknown developer. They use established tools: SecureDrop, Signal, Tor Browser, established anonymizing networks with years of peer review.
The users who would use a new tool are typically people who want decentralized publishing for less severe reasons — avoiding platform deplatforming, building censorship-resistant communities, etc. These users don't need the Tor layer. The UX overhead of routing through Tor killed adoption among the users who were actually interested.
I built for the extreme threat model and got almost nobody. A simpler tool that did IPFS publishing with wallet-based identity (no Tor, much better UX) would have served more people.
Regret 6: The AgenticIdentity ML Model Was Overfit to Available Data
AgenticIdentity used a TensorFlow model to compute reputation scores from onchain and offchain signals. The training data was: transaction frequency, DeFi participation breadth, governance voting history, GitHub contribution graphs, some social graph data.
The model worked. The scores were internally consistent. The problem: the training data skewed massively toward power users who were active across many protocols. Regular users — someone who uses one DeFi protocol, holds some tokens, occasionally votes — scored poorly not because they were less trustworthy, but because their behavior looked sparse compared to the training distribution.
I caught this during testing and added a normalization layer that helped, but the underlying problem is that I didn't think carefully enough about what I was actually measuring. I was measuring "how much does this person look like a crypto power user" and calling it "reputation." Those aren't the same thing.
The right approach would have been to start with a specific, narrow use case for the reputation score — say, "likelihood to repay a DeFi loan" — and build the training pipeline around data that actually predicts that outcome. Instead I built a general-purpose reputation score, which meant it was optimized for nothing in particular.
The Three Principles I Now Apply Before Starting
After writing all of that, here's what I actually changed about how I work:
1. Write the "why not a database" answer before writing code.
One sentence. If you can't write it, stop and think harder. This has killed several ideas I was excited about, which is a feature not a bug.
2. Design the worst-case user experience before the best case.
Not as a UX exercise — as a systems design exercise. What does the user experience when an oracle doesn't resolve? When a bridge is down? When there's no liquidity? The answers to these questions determine more of your architecture than the happy path does.
3. The first 100 users have different economics than the next 10,000.
This is the cold-start lesson generalized. The people who try a new protocol when TVL is $50k, when the community is tiny, when the risk is highest — they need a different deal than users who arrive after product-market fit is established. If you don't design for this explicitly, you'll accidentally punish your earliest and most important users.
What I'd Delete
You asked (the title asked): what would I delete?
CorRealm, as I built it. I'd rebuild it as a single-player game that proves the AI NPC concept, then add blockchain for asset ownership once the gameplay loop is actually fun. Blockchain-first and fun-second doesn't work for games.
PressProtocol's Tor integration. The IPFS + crypto identity stack is genuinely useful. The Tor layer was architectural overreach for the actual user base.
AgenticIdentity's general-purpose reputation model. Replace with three narrow, specific reputation signals, each with clear use cases, and let applications combine them.
Everything else I'd keep. Even the mistakes, because they're in production, and production feedback beats the cleanliness of a design you never shipped.
The projects mentioned are all open source. I try to document decisions, including wrong ones, in commit messages and readmes — because future me is always better at reading than future me is at remembering.