· 4 min read

Day 6: The Solitaire Empire

solitaire tri-peaks spider klondike architecture speed

I’m on a chairlift at Mammoth Mountain. It’s snowing sideways. My daughter’s next to me. And I’m shipping software.

I woke up this morning with one game live. By the time we called it quits on the mountain, I had four. And six domains.

The System Makes It Possible

Here’s the thing — I’m not writing code on a chairlift. I’m not even looking at code. I’m sending voice messages to Sully on Telegram, reviewing screenshots, and saying things like “build Spider Solitaire” and “the mobile layout is jacked up.” The SULLY-WORKFLOW handles the rest.

The system I built over the past week — planning docs, Trello cards, sub-agents that pick up work autonomously, self-review, testing, deployment — that’s what’s doing the heavy lifting. I’m the architect. The system builds.

Tri Peaks: 8 Minutes to a Full Game

Between runs, I told Sully to build Tri Peaks Solitaire — the pyramid card game where you match ±1 from the foundation.

The sub-agent built it in 8 minutes and 28 seconds. A complete card game — 3-peak pyramid layout, face-down cards that flip, ±1 matching with King-Ace wrap, streak scoring, confetti, animations — in under 9 minutes.

13 new files. 63 new tests (bringing the total to 220). Deployed and playable.

The reason it was this fast: the shared architecture. When we scaffolded Golf Solitaire, we put the renderer, models, and analytics in src/shared/. Tri Peaks just needed its own engine and game-specific logic. Everything else was reused.

This is the payoff of good architecture. The investment in shared code on Day 3 made Day 6 possible.

Spider Solitaire: Same Story

Spider Solitaire was next. 1/2/4 suit modes, 10 columns, group moves, auto-remove King-to-Ace sequences.

Another sub-agent. Another ~8 minutes. 14 new files, 43 new tests (263 total), 1,941 lines of code. Live at playspider.games (domain bought same day).

I checked the deploy from the lodge over hot chocolate. It worked.

The Domain Strategy

This is where it gets interesting from a business perspective. Each game gets its own exact-match domain:

  • freesolitaire.games — umbrella site, game selector
  • golfsolitaire.free — Golf Solitaire
  • playspider.games — Spider Solitaire

All pointing to the same Vercel project. Zero extra hosting cost. The domain-based routing detects which hostname you’re on and serves the right game.

From an SEO perspective, exact-match domains still carry weight for game-related searches. Someone Googling “golf solitaire free” hits a domain that literally matches their query.

Code Review: Keeping Honest

After shipping three games in rapid succession, I called a timeout. The sub-agents had been bypassing the SULLY-WORKFLOW — cowboy-coding features without proper planning, review, or documentation. The result? Code that worked, but wasn’t up to standard.

I told Sully to stop and audit the entire codebase. The review found real issues:

  • 🔴 3 Critical bugs: Spider hit detection failing on short columns, GameRouter memory leak (event listener never removed), mutable state in Tri Peaks pyramid nodes
  • 🟡 8 Important issues: SEO hardcoded for Golf only, canvas resizing every frame (performance), no keyboard accessibility for Tri Peaks or Spider

This is what happens when you skip the process. Speed without discipline creates debt. We created Trello cards for all of them (CR-1 through CR-8) and shipped every single fix. PRs #33-40, all through the proper SULLY-WORKFLOW.md process this time.

Klondike: The Classic

With the code cleaned up, I couldn’t resist. Klondike Solitaire — the one everyone thinks of when they hear “solitaire.” Draw-1 and draw-3 modes, auto-complete, double-click to foundation.

Plan session → PRD → 18 Trello cards → sub-agent build. Two sub-agent runs (first hit the context limit), and it was live. 66 new tests. freeklondike.games (plus freeklindike.games for the typo — yes, I bought the typo domain for the 301 redirect).

End of Day 6

The scoreboard:

  • 4 games live: Golf, Tri Peaks, Spider, Klondike
  • 6 domains configured and serving
  • 339 tests passing
  • 41 PRs merged
  • All critical bugs fixed
  • Full code review completed

One week ago, I set up an AI assistant on a Raspberry Pi. Today I have a portfolio of four polished solitaire games, each on its own domain, with shared analytics, accessibility, and mobile optimization. And I built most of today’s output from a ski resort.

Takeaway: The goal isn’t to work harder or faster. It’s to build a system that works without you. Good architecture on Day 1 means new games in 8 minutes on Day 6. A solid workflow means you can ship from a chairlift. But speed without quality is tech debt — the code review caught 3 critical bugs that would have bitten users. Build the system, trust the system, audit the system.

Want to ship like this?

Learn about Ship with AI →