The work happens in two places that can’t see each other. Planning happens in a Claude Project, where Claude brings evidence, options and trade-offs and I make every key decision. Building happens in Claude Code sessions in the cloud, each started fresh from a prompt. Neither one can read the other’s chats, and there are several planning threads as well. So the thing that holds the project together is a GitHub repo, and I treat it as the only record.
The repo is the record
Every planning document lives in the repo in full: the research, the syllabus, the programme design, the build brief, the hazard log and the decision log. A Claude doc, a chat or a memory note is a working copy at best. If one disagrees with the repo, the repo wins. A thread that changes a document updates the repo copy in the same piece of work, and a thread that produces reasoning a later thread will need writes it down there. Each planning thread begins by reading the README and the open decisions in the decision log.
The decision log has a row for every decision, with the date, what was decided and why. Some rows are long, because a build session’s choices are logged with the gap each one filled, so I can confirm or change any of them. The aim is to be able to change my mind later without working out why I decided something.
A file called CLAUDE.md holds the rules for build sessions: the nine safety rules, the product constraints and the allowed dependencies. Every build session reads it first.
Planning, then building
The plan runs in chunks with two gates:
- 18 October. Research and Gate 1: use something that exists, or build. I chose to build.
- 19 October. The syllabus map, then the programme design with its core loop.
- 20 and 21 October. The build brief and the tech stack, which finished four days early so building could start before a family holiday.
- 21 and 22 October. Build sessions 0 to 5b, which produced the first module.
- Gate 2, the playtest with my own children, planned for 1 November at the latest.
- Early November. One more module, chosen at Gate 2.
- After that, a portfolio write-up, which is what these pages are.
All the content for the first module was written in the planning thread and reviewed by me before any building started. A build session loads it and tests it. It can make a mechanical change, like renaming a field, and has to log it. It never changes wording, feedback tiers, source codes or what a scene is meant to show. That put the careful thinking where it costs nothing from the credit, and left the build sessions to do the part that needs the credit.
Each build session starts with no memory of the Project, so its prompt has to carry everything: the scope, a reading list, the stop rules and how to finish. Getting those prompts right is a job in itself. One of them put a van the wrong way round, as described under decisions and dead ends.
The budget
I have a $100 Claude Code cloud credit that expires at 07:59 GMT on 5 November 2026. Unspent credit is lost, so the schedule is fixed to that date. Planning in the Project doesn’t draw on it, and I spend it only on build sessions.
Each build session has a step cap, worked out from the cost of one step. It stops when it reaches the cap, whether or not it has finished, and reports how many steps it took. Cloud sessions can’t report their own cost, so I read the spend from my usage page and bring it back to the planning thread. The estimates have so far run well above what sessions actually cost, and I’ve kept them as stop limits and not cut them, because the later sessions are bigger.
The model choice came out of the same numbers. Using Opus for every build session would have cost more than the whole credit for the first module alone. So every build session runs on Sonnet 5.5 at medium effort, and Opus is only for a named job a Sonnet session reports it can’t do. Planning stays on Opus at high effort. This was my decision, made on Claude’s estimate: careful planning is what lets the build run on the cheaper model.
If the credit runs short, there’s a cut order, applied from the top: the second module of the early-November session, then polish, then the page for reviewing audio clips, then quality checks on weeks 3 and 4, then the calendar and print features.
The whole programme is bigger than the credit, so most of it gets built afterwards on my regular plan, more slowly. How I do that gets decided at the playtest.
What this has shown me so far
The split works, with one catch. A build session is only as good as its prompt, and the wrong-way van came straight from one. Testing on real devices found things the automated tests couldn’t. After my first test of the interface on an iPad and a PC, a single build session took thirteen display and flow fixes. When my family raised two points in testing, the first (looking is corrected but listening isn’t) was already in the log with its reasons, and the second became a new hazard, H30.