How We're Building Salty Poker: Spec-Driven Development
Most poker platforms are built the way most poker hands are played – fast, on feel, figuring it out as you go. We’re not doing that.
From day one, we made a deliberate choice to build this platform using spec-driven development. It’s a methodology gaining serious traction in AI-assisted engineering circles, and it’s the foundation everything we are building sits on.
What Spec-Driven Development Means
Before a single line of production code was written, a specification was written first. Over 100 pages of it. Twenty-three modules covering every domain of the system – infrastructure, database schema, API contracts, service boundaries, compliance controls, CI/CD pipelines, operational runbooks.
The methodology breaks down into three levels. Spec-first: a a thorough spec is written before any code, then used to drive development. Spec-anchored: the the spec stays alive and evolves alongside the codebase as the project matures. Spec-as-source: the the spec is the only thing the human ever touches – the code is entirely generated from it.
There’s also a failure pattern worth naming: spec-once – where a spec launches a project and then gets quietly abandoned as the build gets deeper. The blueprint becomes a relic.
We’re explicitly designed against that. Our spec is a living document. it gets updated as decisions get made, as edge cases surface, as the architecture evolves. When a session ends, the spec reflects what was built. When the next session starts, it picks up exactly where the last one left off.
Why This Matters for a Poker Platform
Poker platforms fail in predictable ways – and almost all of them trace back to the same root cause: shortcuts taken early that compound into serious problems later.
A wallet system built without a proper double-entry ledger. A game engine that hasn’t been stress-tested for edge cases. A compliance layer bolted on after the fact instead of baked in from day one. A platform that works fine with 50 players and collapses at 500.
Spec-driven development is the discipline that prevents that. Every service boundary is defined before it is built. Every data flow is documented before it is implemented. Every compliance requirement is in the spec before a single migration runs. There are no “we’ll figure that out later” decisions – because later is when players are at the tables.
Agentic AI as the Execution Engine
We’re using agentic AI to build this platform – and there’s an important distinction between that and the AI tools most people are familiar with.
Agentic AI doesn’t just answer questions or autocomplete code. it executes multi-step workflows autonomously within defined boundaries – write the code, run the tests, catch the failure, fix it, commit – without needing a human to supervise every action. it works through a task end to end and hands control back when it hits a decision reserved for a human.
The spec is what makes that safe and predictable. The agent operates from a defined, reviewed, version-controlled specification. Each session loads a focused subset of modules – two to four at a time – giving the agent exactly the context it needs and nothing it doesn’t. Each session has a defined scope. A checkpoint gates the next phase. Nothing advances until the checklist is clean.
The agent doesn’t decide what to build. The spec decides. The agent executes.
The Result
A platform built with the rigor it deserves. Every architectural decision documented. Every service boundary intentional. Every compliance requirement addressed before it became a problem.
That’s what we are building. And you’ll feel the difference when you play on it.
For more on the methodology: Using Spec-Driven Development with Claude Code by Heeki Park – https://heeki.medium.com/using-spec-driven-development-with-claude-code-4a1ebe5d9f29
