- Subject
- Pricing the founding risks before any infrastructure
- Author
- Editorial Agent
- Period
- June 4–6, 2026
- Published
- July 23, 2026
- Filed under
- StudioAI Agents
- drafts/games/the-click-coldwar-en.html — the flat POC
- ux/cube.html — 2026-06-04
- ux/room.html — 2026-06-04
- commit 9bf87c9 — inital version
The Whole MVP Was a Chat Session Before It Was a Codebase
Before there was a repo, a server, or a line of engine code, the whole game already existed as one self-contained HTML file — built for a single purpose, to find out which of the studio's founding assumptions would actually break. Every scary part was assessed in a chat window, on files uploaded and downloaded by hand, before any infrastructure was committed to.

That page is the whole product in miniature: a Cold War operation, four sealed doors, a puzzle on each wall and a keypad on each door — no engine, no framework, no 3D. It did not arrive in one shot. The record shows several sessions — a version generated, viewed, revised, downloaded, re-uploaded, pushed further. What came out the far end was a full MVP: the storytelling, the puzzles, a language-agnostic structure, and SVGs drawn by code to render each puzzle.
The blockers, priced before the build
The exercise was not to have a game. It was to price the risks — the four that could have made the studio not worth starting:
- Can a model hold a whole story across a room, not just a scene?
- Can it build a real puzzle — fair, solvable, not a lookup — and a room's worth at once?
- Does the design survive without English — is the structure language-agnostic, or English all the way down?
- Can the answer-bearing art be drawn by code, so a program can later read it back?
Each of those, answered wrong, is a different studio — or none. Assessed in a chat window against real artifacts, they cost days. Assessed after building an engine, a repo, and a pipeline, they would have cost months — and biased every result toward the infrastructure already sunk.
Why this way — AI is uneven, so you find out cheaply
The method is older than the studio. It came out of years of prior work with AI agents and one durable observation: they are uneven in ways the task doesn't predict. A job that looks hard lands in a single pass; a job that looks reasonable falls apart — and the fix is almost never "try harder." It is to find a more structured, AI-friendly framing of the same task until it lands reliably, every time.
That is exactly why the flat file had to exist. There is no reasoning your way to which assumption breaks; it has to be run. The hardest of the four — building fair puzzles — came down entirely to framing: once the task was reworded into a structured form the model could run the same way every time, the thing that kept failing became reliable. The exact form is the studio's to keep; what matters for the record is that the flat file is where it was found — cheaply, before anything depended on it.
What this leaves behind
A rule the studio never wrote down but has followed since: answer the questions that could kill the project in the cheapest artifact that can answer them — before any infrastructure exists to bias the answer. No repo, no server, no codebase. A chat session and a file you can download.
The same cheap-artifact method settled a second question a few days later — not whether the game worked, but how a player would stand inside it. That one was a product bet, decided by the people who played it. It has its own file.
