I Shipped a Lot of Web3 Projects. Most of Them Taught Me the Same Thing.

For about a year I was shipping something new every few weeks. Hackathons, side projects, ideas I couldn't stop thinking about at 2am. If you open my GitHub you can see it: PredictX, Resolutions, CoreRealm, NFTsea, AgenticIdentity, SonicAgentHub, NebulaID, UACP, a terminal-style portfolio, and a bunch more I'm too embarrassed to name.

I'm not going to pretend all of them were good. Some were fun, a couple won things, and a lot of them I'd build very differently today. So this is me going back through them and being honest about what I actually learned, because the weird part is most of them taught me the same lesson over and over and I kept not listening.

PredictX: the oracle is the product#

PredictX was a prediction market. You bet on an outcome, an oracle resolves it, money moves. I spent most of my time on the contracts and the order book, because that's the part that feels like engineering.

Looking back, that was the wrong half. The matching logic is the easy part. The real question in a prediction market is "who decides what actually happened, and what do you do when they're wrong or slow?" A market on "will this team win" is easy. A market on "will this protocol hit $1B TVL by Q3" needs someone to interpret things, and the second you need interpretation you need disputes, and appeals, and a way to keep people's money safe while that's happening.

I treated resolution like a detail. It's not. If I built it again I'd start with the resolution and dispute design and only then write the trading part.

Resolutions: I built a mechanism, not an incentive#

Resolutions is probably my favourite idea from that whole stretch. You put money on a goal. Hit it, you get it back. Miss it, it goes somewhere else. Skin in the game for actually doing the thing you said you'd do.

The hard part is obvious once you say it out loud: a smart contract has no idea whether you went to the gym. Somebody has to vouch for you. My answer was a friend or a small group confirms it, and disputes go to a jury.

Technically fine. But I never gave the people verifying anything to gain. They were doing it as a favour. And honestly, if your friend asks "did I hit my goal?" you're going to say yes. That's not a verification system, it's just a group chat with a smart contract attached.

If I come back to it, verifiers need their own stake: they put something up, they get paid for being right and lose it for lying. More complicated, but at least it would work for people who aren't your best friend.

CoreRealm: "why is this on a blockchain?"#

CoreRealm was a game on CoreDAO with AI-driven NPCs whose state lived onchain. Super fun to build. Agents reading game state and reacting to it was genuinely one of the more interesting things I've hacked on.

But I have to be honest about why I built it: it was technically interesting. That's it. Nobody playing games was asking for NPCs with onchain memory. What people in web3 gaming actually cared about was owning and trading their stuff.

This is where I came up with the question I now ask before every project: why not just use a normal database? If the answer is something like "people who don't trust each other need to settle money", or "this content will get taken down anywhere else", or "users should actually own this", fine, that's real. If the answer is "because it's onchain", it's not real, and CoreRealm's answer was basically "because it's onchain".

NexusFi: liquidity is a design problem#

NexusFi is different from the rest of this list because it wasn't a hackathon build. I co-founded it. It was liquid staking and restaking on Nibiru, and I still think the protocol design was solid.

What we didn't take seriously enough was the cold start. Staking yield looks good when there's a lot of TVL, there's a lot of TVL when yield looks good, and on day one you have neither. It's a loop and you need some way to break into it: someone committing a big chunk of liquidity, aggressive incentives, or a partner sending people your way.

The mistake I'd call out is treating that as a marketing problem. It's an economics problem. The first people who show up are taking the most risk, and they should get a better deal than whoever turns up after it's working. If you don't design that in from the start, you basically punish your earliest users for trusting you.

AgenticIdentity: measuring the wrong thing#

AgenticIdentity tried to give a wallet a reputation score using onchain activity plus some offchain signals like GitHub and governance votes.

The scores were consistent, but at some point I realised what I was really measuring was "how much does this wallet look like a crypto power user". Someone who uses one app, holds a few tokens and votes now and then would score badly, not because they're less trustworthy but just because they're less active. That's not reputation, that's activity.

What I'd do now is pick one narrow question, like "will this person repay a loan", and build the score only around data that actually predicts that. A general-purpose reputation score ends up being good at nothing.

What I actually changed#

If I squash all of that down, it's really one habit: before I write code, I write one sentence answering "why not just a database?" If I can't write it, I stop. This has killed a few ideas I was really excited about, and I'm glad it did.

The second thing is I now think about the bad day before the good day. What does someone see when the oracle doesn't resolve, the bridge is down, or there's no liquidity yet? Those answers end up shaping way more of the architecture than the happy path ever does.

And the third one, mostly thanks to NexusFi: your first hundred users are not the same as your next ten thousand. Treat them differently on purpose.

I don't regret building any of these, by the way. Shipping something half-wrong taught me more than any design doc I never finished. Most of it is still up on GitHub if you want to poke around, mistakes included.