Over the Christmas break, my nephew Zaeem pitched me a card game. He didn't have a rulebook, a spec, or a product requirements document. He had a feeling—the kind of gut-level game instinct that makes UNO work, that makes kids slap cards down on tables and scream.

Cards that attack. Cards that block. Cards that reverse things suddenly.

That was the whole brief.

What I saw in Zaeem's idea wasn't a kid's hobby project. It was pattern recognition. There was something structurally sound underneath the chaos. A natural competitive loop, high interaction between players, and the potential for moments that make card games addictive.

But the first iterations were a mess. Too many "it depends" situations. No clear resolution order. Players constantly asking: "Can I reverse this?" "Does this block that?" "Who does this go to now?"

The game was fun, but only if someone explained it live. That's not a product.

The breakthrough was a triangle: Attack → Defence → Reverse.

A closed loop simple enough for a child to grasp instantly, structured enough to prevent "anything can do anything" chaos. Reverse cards, the most interesting and most dangerous mechanic, got split into three tiers, each with distinct behaviour. Standard redirects basic attacks. Special escalates the chain. Ultimate ends all ambiguity.

Every design decision after that followed the same principle: simplicity over cleverness. Status effect cards (Poison, Doom, Mystic Fire) resolve independently from the attack triangle. They can't be defended or reversed. Healing cards only work on yourself, which killed kingmaking and kept the rules clean.

120 cards. 2-12 players. 100 HP. Draw one, play one, last player standing.

A system.

I wrote three documents before touching any code: a product requirements document, a developer game spec, and the complete rulebook. This was deliberate. The code would follow the system.

Then came one of the most intense build sprints I've done. 53 commits across 4 days, December 26-30, 2025. Built with Claude Code as my engineering partner.

Day 1 started at 8:19 AM with the first commit: a monorepo with client, server, and shared packages, a command-event reducer game engine, WebSocket infrastructure, React frontend with Zustand state management, and 105+ sound effects across nine categories. Six substantial commits. Zero to playable in a single day.

Day 2 was deployment hell. Vercel couldn't handle the monorepo's shared package dependency. I pivoted to Railway and spent five configuration commits in 80 minutes fixing root directory settings, build command order, and a duplicate npm install that broke everything. What should have taken 30 minutes took three hours. Between the deployment chaos, I shipped haptic feedback for mobile, particle effects, and holographic card animations. The first commits landed at 4 AM. Copy-paste accidents at that hour told me the pace was unsustainable. But the momentum was hard to stop.

Day 3 was the reckoning. Real users touched the game, and reality hit. A comprehensive bug report listed everything from an unresponsive play button to missing NSFW name filters. The mobile UI was redesigned three times—thumb-zone optimisation at 2 AM, drag-to-play gestures by evening, then a compact status strip that only stuck because it was the simplest of the three. I added AI bot opponents not as a feature but as a testing necessity. You can't playtest a multiplayer game alone. By the end of the day, 152 tests covered game logic, damage calculation, status effects, component rendering, and accessibility.

Day 4 was polish. Theme system with CSS variable infrastructure. Kid-friendly copy rewritten for 6-16 year olds. WCAG accessibility improvements. Gameplay music with fade transitions. And post-deployment bugs that specs can't predict; pause/resume state corruption, notification stacking, turn order edge cases when players get eliminated in specific sequences.

The last commit landed at 12:35 AM on December 30.

Specs-first development works. Writing the PRD, game spec, and rulebook before code meant the sprint had a clear target. There was no ambiguity about what "done" looked like. The reducer pattern, the message schemas, the attack resolution flow; all defined before the first line of code. Without those documents, four days would have produced a prototype. With them, it produced a product.

The gap between rules and UX is where the real work lives. A perfect rulebook doesn't mean players understand what's happening during play. The attack resolution UI, the timer rings, the "what's happening now?" prompts, none of that was in the spec. All of it was discovered through playtesting. Design on paper and design in practice are different disciplines.

Audio isn't a nice-to-have. Designing the sound system on Day 1 with frequency palettes, layered feedback, and volume tuning made the game feel polished from the first playable build. Most projects bolt on sound at the end and it shows.

AI-assisted building changes the equation, but not the way people think. Claude Code didn't replace the need for clear specs, architectural decisions, or design judgment. What it did was compress the execution timeline so dramatically that a solo builder could ship what would normally take a small team several weeks. The bottleneck shifted from "can I code this?" to "do I know what I want to build?" That's a fundamentally different constraint, and it rewards people who think in systems.

This wasn't a technical exercise. It was taking an 11-year-old's intuition plus imagination and adding enough structure to make it real without killing what made it exciting.

Zaeem plays Drawn Destiny with his friends now. They argue about Reverse card chains and groan when someone plays a Doom card at the worst possible moment. The table erupts the way he imagined it would when he first described the game to me.

That's the part no commit log captures.

53 commits. 152 tests. 105 sound effects.

A kid's idea, running on WebSockets at drawndestiny.org