Day 3: From Idea to Code in One Session

Yesterday I brainstormed a bunch of ideas. Today one of them became real code. In a single session.

The Idea: Golf Solitaire

It came out of the brainstorm pipeline. Card games. Simple, browser-based solitaire games. Free-to-play, ad-supported, SEO-optimized with exact-match domains.

I ran it through the ACR filter:

Autonomy: 5 — solo project, no dependencies on anyone
Complexity: 4 — real engineering (canvas rendering, game logic, mobile optimization) but not overwhelming
Reward: 4 — passive ad revenue, great portfolio piece, fun to build, SEO learnings

Total: 13/15. That’s a green light.

We decided to start with Golf Solitaire — it’s the simplest variant. One tableau, one foundation, draw from stock. The rules fit on a napkin, but making it feel good to play is the real challenge.

The Tech Stack Decision

Sully and I had a real conversation about this. React? Too heavy for a card game. Phaser? Gaming framework overhead for something this simple.

We landed on vanilla TypeScript + HTML5 Canvas. Zero runtime dependencies. Vite for building, Vitest for testing. The whole bundle would be tiny — we’re targeting under 20KB gzipped.

Why Canvas instead of DOM? Cards need smooth animations, overlapping elements, and precise hit detection. Canvas gives you a pixel-perfect rendering loop without fighting CSS layout.

Scaffolding the Architecture

Here’s where it gets interesting. I didn’t write the code. Sully didn’t write the code. A sub-agent wrote the code.

OpenClaw supports sub-agents — basically, you spawn a focused Claude instance for a specific task. Sully created a detailed planning doc (the PRD for Golf Solitaire), broke it into Trello cards, and then a sub-agent started building.

The planning doc was the key. It had everything: game rules, architecture decisions, file structure, acceptance criteria. The sub-agent didn’t need to make judgment calls — it just executed.

In about 45 minutes, we had:

Card model with suits, ranks, face-up/down state
Deck with Fisher-Yates shuffle
Golf engine with full game logic
Canvas renderer drawing cards
89 unit tests, all passing

That’s not a toy. That’s a foundation.

The Architecture Choice That Paid Off

One decision Sully pushed for (and I agreed with) was separating the engine from the renderer. The engine is pure logic — no DOM, no Canvas, no browser APIs. It takes actions and returns state. The renderer reads state and draws.

Why does this matter? Three reasons:

Testability — engine tests run in Node, no browser needed
Portability — same engine could power a React version, a terminal version, whatever
Reusability — other solitaire games can share the renderer and card models

That last one is the big one. We’re not building one game. We’re building an engine that can power many games.

Takeaway: The gap between “idea” and “running code” is mostly planning. A detailed PRD + clear architecture + sub-agent execution = working software in under an hour. The AI didn’t replace the thinking — it executed the thinking at machine speed.