Swarm Chess

End to end, live 24/7

Swarm Chess is my demonstration of end-to-end delivery. It isn’t a prototype or a demo build. It is a real product with real players, running in production 24 hours a day, and I own every step:

• product idea and design
• frontend, backend and database
• testing and CI/CD
• deployment and hosting
• monitoring, backups and releases

New versions ship while people are playing, without taking the site down for them.

Why

It started as a trainer for my own chess: drills built from my mistakes and practice for the openings I play. Then came the question that gave it its name: what if a whole team played one side, voting on every move?

What it does

• Swarm Chess. Many players control one side by voting on each move, up to 1,000 players in one game.
• Everything else a chess site needs. Play against Stockfish or a friend, tournaments, and training built from your own mistakes.

How it’s built

• Frontend: React and TypeScript, with Stockfish running in the browser as WebAssembly.
• Backend: Python FastAPI with Stockfish on the server, so even a phone gets a full-strength analysis.
• Data: PostgreSQL, with live updates for votes, moves and chat sent to every player over server-sent events.
• Running it: Docker containers behind Caddy on one small server, deployed with a single script.

Built by agents, shipped safely

Most of the code is written by AI coding agents (Claude Code), several at once, each in its own git worktree and branch. They work from a shared rulebook in the repository, so every session follows the same rules on shipping:

• CI on every push. GitHub Actions runs type checks, lint, the frontend tests and a build, then the backend’s unit tests against a real Stockfish, on every push and pull request. The workflow has read-only access to the repository, and its actions are pinned to exact commits.
• No stale deploys. The deploy script refuses to ship unless the tree contains the latest dev and has no uncommitted changes, so one agent can never roll back another agent’s work.
• Every visible change is a release. An agent that changes something a player would notice must bump the version and add a plain-language entry to the in-app “What’s New” panel. The version is served from one source of truth.
• Database changes are migrations. Schema changes go only through numbered, idempotent migration files that register themselves. Agents check for drift before touching the schema, and anything destructive waits for my yes.

Updates without breaking games. A deploy announces maintenance to everyone online and builds the new images during a two-minute countdown. It then ends the unfinished games cleanly and switches over. A sweep requeues tournament matches cut off by the restart, so no bracket gets stuck. A browser tab still running the old version reloads itself the moment it asks for code that no longer exists, guarded so that it can never loop.

Where it stands

Live in production at swarm-chess.com, running 24/7.