Why build it this way: the marginal cost of a game is the whole bet¶
Every other post in this catalog explains a mechanism. How a screen description becomes a buildable spec. How a ticket flows through the orchestrator. How a code annotation makes a refactor safe. How a lesson learned building one game folds back into all the others. They are good posts and they are all, in a sense, downstream of one decision that none of them argues for directly, because they assume it.
This post argues for it.
Here is the thing a reader can follow every mechanical post and still miss: the central bet of this project is economic, not technical. None of the machinery exists because it is elegant. It exists to crush a single number -- the marginal cost of adding a new game -- and if you do not know that number is the target, the whole apparatus looks like over-engineering. Once you do know it, the apparatus looks like the only sane response to the problem.
So before any of the how-to, the why. The why is a number, and a bet about how to move it.
The bottleneck is the per-game engine, and money does not fix it¶
Start with the business this is supposed to become: a catalog of board games you can play with friends on a TV and your phones, with AI opponents and a coaching layer on top. A catalog. Not one game -- a marketplace's worth.
The honest accounting of what stands in the way lives in the overview docs, Section 7, and it is bluntly titled "The real bottleneck (and why money doesn't fix it)." The instinct, when you imagine scaling a games platform, is that the constraint is awareness -- you need ads, you need a launch, you need people to know it exists. And for a single standalone app, that is roughly true: a store handles distribution, and money buys awareness.
But a catalog has a different constraint, and money does not buy your way past it. The bottleneck is per-game engine implementation cost. As that doc states it plainly: right now each new game is roughly a phase of work. A marketplace model only pencils out if the marginal cost of adding a game drops to something like "designer hands you a rulebook and a spreadsheet, and a working engine comes out the other side in an afternoon." A catalog never reaches the size a marketplace needs if every title is a multi-week build. You cannot ad-spend your way out of a supply problem. You can only build your way out of it -- by making each unit of supply radically cheaper.
That is the sentence to sit with: the marginal cost of a new game has to fall from "a phase of work" to "a designer-in-the-loop afternoon." Everything else in this project is in service of that drop.
The architectural bet that is supposed to make the drop happen is AI-assisted authoring. The plan, as Section 7 describes it, is to feed a rulebook plus the per-game design template to a strong model and ask it to generate a candidate GameEngine subclass plus its tests -- with a designer in the loop reviewing the result, not blindly trusting it. The companion framing in the overview docs puts the same claim in one line: the AI-assisted authoring pipeline is the bet that changes the per-game cost "from a phase of work to a designer-in-the-loop afternoon." Same number, same bet, stated from the business side and the architecture side.
This is the load-bearing idea under the entire catalog. Every durable doc, every ticket, every guardrail, every retro you will read about in the other posts is, at bottom, an attempt to make that afternoon real and repeatable.
The per-game design doc does double duty, on purpose¶
Here is the part that makes the bet plausible rather than wishful, and it is the most elegant structural decision in the whole project: there is one artifact that is simultaneously the prompt that generates an engine and the contract a publisher hands you. It is the per-game design doc.
Every game in the catalog has a design doc under the game docs -- the game docs, the game docs, and the rest. The structure is consistent across games: rules summary, framework decisions, state model, action vocabulary, the three role-filtered views, AI surfaces, post-game slots, computer opponents. That structure was not designed to look tidy. It was designed to be a template you fill in, and it is read in two directions at once:
- the overview docs calls that per-game design doc structure "effectively the publisher handoff template" -- the form a board-game publisher fills in so the rest of the platform can be built around their game.
- the overview docs, Section 7, calls the same structure "effectively the prompt-template" for the AI-assisted authoring pipeline.
It is both. The same filled-in form is the publisher's handoff and the model's prompt. A designer fills in the template; the engine and its tests come out the other side, mediated by an AI and checked by a human. The engine that comes out is not freeform -- it subclasses the GameEngine ABC in the engine base contract, so "a working engine" means a concrete thing with a known shape, a known set of methods to implement, and a test surface that already knows what to assert. The template constrains the input; the base class constrains the output. That is what turns "ask an AI to write a game" from a party trick into a repeatable pipeline.
This is why the project is so insistent about durable, structured docs -- a theme the on-ramp post, From an idea in a chat window to a repo the robot can build, spends its whole length on. A design doc that is just prose is a nice read. A design doc that is a template is a machine input. The whole catalog is built on treating the second thing as the real artifact.
Where the afternoon pays off: a value ladder, framed as strategy¶
Suppose the bet works and a new game really does become an afternoon. What does that unlock on the business side? This is where I have to be careful, because the answer is genuinely interesting and also entirely speculative -- so I will flag it as what it is. The following is strategy thinking, not a shipped product.
the overview docs sketches a three-tier AI access ladder, framed there explicitly as a thing to explore and not a commitment:
- Free tier -- phone-side MCTS only, template commentary, works offline. No server-side AI cost beyond hosting the game itself. (the overview docs describes this MCTS path as running locally on the phone via a compiled engine -- the search needs no training data, just the engine's own move-application logic.)
- Platform tier -- server-side AI, with the platform providing the LLM key for commentary and coaching, under a subscription.
- Premium tier -- bring-your-own-key (BYOK): the player supplies their own LLM API key and pays their own model costs directly. Better commentary continuity and personalization, and -- this is the unusual part -- the platform's cost for that user goes down, not up.
That last point is the one worth lingering on, and the STRATEGY doc calls it out as the key insight: the premium tier is where player experience goes up while platform cost goes down at the same time. That is an incentive alignment you almost never get -- usually your best customers are your most expensive ones. Here the best experience is the cheapest one to serve. I find that genuinely elegant, and I am also not going to pretend it is proven. It is a sketch of how a ladder could work, written down so the thinking is not lost.
The honest current state: the overview docs is clear that v1 ships BYOK only, deliberately, to avoid building subscription infrastructure before there is anything to subscribe to. Today every user is effectively "premium" because there is no platform-billed tier at all. The ladder is a map of where the model could go, not a price sheet you can sign up for.
The Publisher-Platform angle lives or dies on the same number¶
There is a B2B version of the same idea, and it is the one the overview docs treats as the most fleshed-out: the Publisher Platform. The pitch is to be the "online partner" for board-game publishers who want a digital version of their in-print game but have neither the in-house tech nor the appetite to build one. The publisher hands over rules, art, and theme; the platform supplies the engine, the multiplayer, the cross-device UI, the AI opponents, the advisor layer, the recap, all of it. Recurring revenue per title, platform keeps a cut.
And the reason that pitch is even sayable is the per-game design doc again. The publisher handoff is filling in that template. The platform's claim to a publisher -- "you keep designing games, we handle digital" -- is only credible if onboarding a new title is bounded work rather than a bespoke build per game. Which is exactly the bet from Section 7. The STRATEGY doc says it directly in its cross-reference: the Publisher Platform does not pencil at scale without the AI-assisted authoring bet -- the one that turns per-game cost from a phase of work into an afternoon -- paying off first.
So the two strategy threads, the consumer value ladder and the B2B publisher angle, are not two ideas. They are two payoffs of the same bet. Both of them are gated on the marginal cost of a game falling far enough. Crush that number and both become possible. Fail to crush it and neither does, no matter how good the pitch deck reads.
The honest edges¶
The genre this post lives in -- "here's the clever strategy behind my project" -- usually stops right before the part where it admits what is real and what is not. I am going to do that part, because the whole framing collapses if a reader thinks I am describing a business instead of a bet.
There is no shipped revenue. None of this is selling anything yet. There is no paid Platform tier -- the subscription infrastructure for it is not built, on purpose. There is no publisher partner; the Publisher Platform is a model on a page, not a signed deal. The three-tier ladder is a sketch in a strategy doc that says, at the top, in so many words, that everything in it is thinking and not a commitment.
The afternoon-per-game number is a bet, not a measurement. I have written "a phase of work to a designer-in-the-loop afternoon" several times in this post. That is the target, quoted from the repo's own docs. It is not a benchmark anyone has hit and timed. AI-assisted authoring of a full, correct, test-passing game engine from a rulebook is plausible in 2026 in a way it was not two years ago -- the GO_TO_MARKET doc makes that case -- but plausible is not proven, and "designer-in-the-loop" is carrying real weight in that phrase. The human review cycle is the part that keeps a generated engine from being confidently wrong, and that cycle has a cost the word "afternoon" is quietly absorbing.
An economic thesis is not a guarantee the economics work. Even if the per-game cost falls exactly as hoped, none of the downstream claims -- that a medium-weight tabletop catalog on TV-and-phones is a real market, that publishers will hand over their games, that the premium tier's cost-down alignment survives contact with reality -- are settled. Those are separate bets stacked on top of this one. This post is about the foundational bet, the one all the others rest on. It is the most defensible of them because it is the one the architecture is actually built to win. It is not the only one that has to be true.
None of these caveats is a reason the bet is wrong. They are the difference between a strategy and a result, and being honest about which one you are looking at is the whole point of writing it down this carefully.
So that is the why under all the how. The reason this project pours so much effort into durable docs, structured templates, a governed orchestrator, and a relentless set of guardrails is not a love of process. It is a single economic conviction: a board-game platform built the normal way -- one phase of work per game -- never reaches catalog scale, and the only thing that changes that math is driving the marginal cost of a new game down to a designer-in-the-loop afternoon. Everything else is in service of that drop.
If this post is the why, the on-ramp post From an idea in a chat window to a repo the robot can build is the where it starts -- how an idea becomes the kind of durable, structured repo this bet requires in the first place. And the capstone, The cross-game compounding flywheel, is the what it buys you over time: it argues that each game built this way makes the next one cheaper and the last one better. The flywheel post is about the slope of the curve once you are on it. This post is about why you would ever decide to get on it. Cheaper-per-game is not a nice-to-have side effect of building with AI. For a catalog, it is the entire game.