John De Goes’ blog

There’s a specific kind of Friday night I’ll never forget. A table, a deck of cards, the smell of rum and coke, and the sound of someone slapping a card down and shouting “¡Truco!” while everyone else erupts. I grew up playing that game. I made friends through it. I made money through it — enough to survive university, honestly. So when I sat down to think about what I’d build as my first solo product, the answer was obvious.

I was going to build a decentralized platform for high-stakes card games. And I was going to start with Truco.

The Idea: Polymarket, But For Games

The inspiration came from Polymarket. I’ve been working in Web3 for a decade, and I’m a true believer in decentralization — not as a buzzword, but as a practical answer to real problems. Centralized gambling platforms are opaque, custodial, and full of regulatory landmines. They hold your money, they know who you are, and they can block your withdrawal at 2am on a Saturday. That friction is unnecessary. Smart contracts don’t sleep, don’t have compliance departments, and don’t hold your funds hostage.

So my thesis was simple: a decentralized gaming platform where every bet is enforced on-chain, every settlement is triggered by an oracle, and the platform never custodies any player’s assets. The game is just the interface. The blockchain is the referee.

Truco was the perfect proof of concept — not just because I love it, but because it’s the kind of game that looks simple on the surface and is deeply, deceptively complex underneath. Anyone who has played Venezuelan Truco knows what I mean. The edge cases alone could fill a rulebook.

I Had Never Built a Game Before

I’ve spent years building products in Web3 — for Ledger, for Mezo, and others. I’ve done years of UX research on crypto user pain points. I know how to ship. But building a game? That was new territory.

The challenge I underestimated most was what I’d call operationalizing the gamebook. Truco — specifically Venezuelan Truco — is a melting pot of edge cases, exceptions, and wow moments. The rules interact with each other in ways that only become obvious when you’re mid-hand at 2am and something breaks in a way you didn’t anticipate. Documenting those rules precisely enough to turn them into code, and then capturing the actual feeling of the game — the tension, the bluffing, the rapid-fire escalation — that was one of the most beautiful and maddening challenges of my career.

Getting the logic right was one thing. Making it feel alive was another.

My Team Is Made of AI Agents

I’m a Product Manager by trade and an agile addict by conviction. My typical workflow isn’t that different from what it’s always been: research, process design, requirement scoping, sprint execution, engineering review, and manual testing. The difference is that my engineering team is now a fleet of AI agents.

I use two tools at the center of everything: Perplexity for deep research and Claude Code for execution. They serve very different purposes, and understanding that distinction was crucial.

Perplexity is my research layer. When I need to understand a new technology, evaluate libraries, compare architectural approaches, or investigate a bug I’ve never seen before, Perplexity is where I start. It connects to my other tools via MCP connectors — I use it to manage my Linear board, read from my repo, and keep the strategic picture clear. It’s a phenomenal learning engine.

Claude Code is where the real work happens. It’s my operational layer, the place where requirements turn into commits. But I want to be honest: both tools have rough edges. Perplexity’s MCP connectors don’t always behave, and support is nearly nonexistent when they don’t. Claude Code, if you’re not careful, is a token-eating machine. Getting it to work efficiently — to actually conserve context, respect scope, and not casually refactor something you didn’t ask it to touch — takes serious learning and deliberate process design.

Neither tool is magic. Both are powerful in the hands of someone who knows how to wield them.

There’s a Difference Between Vibe-Coding and AI-Assisted Development

Let me say something that I think needs to be said more clearly in this industry.

Vibe-coded apps deserve the criticism they get. When someone who doesn’t understand software gives an AI a fuzzy requirement and expects it to make complex architectural decisions autonomously, the result is exactly what you’d imagine: fragile, unscalable, full of technical debt, and broken in ways nobody can explain. The AI isn’t the problem. The lack of accountability is.

AI-assisted development is something entirely different. It’s what happens when someone who already understands the system uses AI to move faster, delegate the operational weight of execution, and focus their energy on the decisions that actually require judgment. I’ve been writing precise, well-scoped requirements for engineering teams for years. I know what good problem framing looks like. The shift was that now I am the one with full accountability — not just for the strategy, but for the implementation.

That’s both the superpower and the responsibility. And when you hold both, something remarkable becomes possible: I shipped this entire product with zero technical debt. That has been a long-standing ambition of mine, something I watched get sacrificed on deadline after deadline in every company I’ve worked in. With AI as my team and agile discipline as my structure, I finally got there.

The First UI Was Terrible. That Was Fine.

At one point I had a working product that was, visually, a disaster. It worked. It was functional. And it looked like it was built in an afternoon by someone who had never played a game in their life.

That was my fault. I hadn’t yet developed the right process for translating design intention into something an AI agent could execute with quality. Once I understood the tooling better — how to audit what had been built, how to describe outcomes rather than just features, how to give precise visual and interaction constraints — the revamp process was genuinely fun. Going from something generic and forgettable to something that actually felt like the game was one of the most satisfying parts of the whole build.

I’m proud of the result now. The UI is clean, fluid, and purpose-built. It doesn’t look like it was generated — it looks like it was designed.

What I Actually Built

Let me describe the platform without getting caught in the technical weeds.

From a player’s perspective, the experience is seamless. You connect, you find a game, you play, you get paid. There’s no custody, no manual withdrawal, no trust required. Everything from bet escrow to payout is handled by smart contracts on-chain, settled by an oracle. Account abstraction means you don’t need to understand wallets to use it. On and off-ramps mean you can move between traditional money and crypto without friction.

The complexity is real — but it’s completely invisible to the user. That invisibility is the product.

The underlying platform is game-agnostic. Truco is the proof of concept, and it’s a great one: fast, tense, social, endlessly replayable. But the infrastructure underneath can absorb any game’s rules in days, not months. It’s lightweight, beautiful, and fast. And because it’s on-chain, it’s fully auditable and respectful of player privacy — no platform ever holds your money, which also removes a significant amount of regulatory exposure.

Think of it as a modern, open casino where the house doesn’t hold the chips.

The Deepest Lesson

If I had to distill everything I’ve learned from this project into a single idea, it would be this:

We are living in the most extraordinary moment in the history of building things. You don’t need to acquire new skills to create what you can imagine — you need to learn how to ask the right questions. The craft is in the framing. The superpower is in the precision of your curiosity. Get that right, and the answers will find you. The tools will execute. And you will be, genuinely, unstoppable.

This isn’t hype. I’ve lived it. I built a game, a platform, and an architecture I’m proud of — alone, in a fraction of the time a traditional team would have taken — because I learned to treat AI not as a shortcut, but as a collaborator that rewards clarity.

What’s Next

We’re launching the proof of concept. The next chapter is building in public — shipping fast, listening to users, iterating visibly. I want to show what it looks like when a platform with this kind of foundation absorbs feedback and evolves in real time.

After that? The world is full of games. The world is full of players. And the platform is ready for both.

If you’ve been sitting on an idea because you thought you needed a team, a budget, or a decade of engineering experience — you don’t. You need clarity, discipline, and the right questions.

Go build something.

John De Goes is a Web3 product leader and builder currently shipping a decentralized gaming platform. He writes about AI-driven development, product craft, and the future of decentralized applications.