The Rented Codebase
The codebase is rented. The blueprint is owned. The tests are the proof.
This is my book — a working paper I’m finalising now, written with Claude as my drafting partner. It’s the thinking behind Gyrum, drawn from actually running the factory rather than theorising about it.
Pre-print draft · finalising toward release
Delete your codebase tonight. Same product, new language, your whole team away — could it be standing again by Monday?
If yes, you own a blueprint, and the code was always rented. If no, you own a description of your product that only your current code can read — and an AI is about to make that code worthless. This book is the difference between the two.
The idea
I built a dark factory: a system of AI agents that takes a one-paragraph product brief and ships a working SaaS product to the public internet. I used it to ship twelve micro-SaaS products in a month — and, looking at the pile, realised I had more code than I’d written by hand in my whole career, every product subtly different, no chance of maintaining the lot.
The fix couldn’t be more code. It had to be standardisation — pulling the shape every product should take into a place outside the code. That place is the blueprint: the spec the factory builds against, the tests that prove the build, the gates that catch what the factory misses. Once a factory can build a product once, the question stops being “did we build it right?” and becomes “can we build it again — the same way, on demand, in any language?”
Tests are the blueprint
The tests that survive a rewrite describe what the product does in operator-facing terms — not what a function returns. Implementation-agnostic, persistent, executable.
Bugs grow the blueprint
Every bug surfaces a clause the operator implicitly expected. The fix makes it permanent, so the next regeneration carries it forward. After enough cycles, the blueprint is the operator’s complete intent.
The codebase is rented
When a factory can rebuild a product from the blueprint, the code becomes interchangeable — different language, framework, architecture. Same product, same contract.
Why it matters now
This isn’t a forecast — it’s a shift already underway. Phase one floods teams with 10× more code and a wave of “AI didn’t work for us” disillusionment. Phase two is the turn: 10× less code against the same product, where the blueprint — not the codebase — is what compounds.
“A thesis being lived, not just tooling — the fleet is the book’s working proof, and the book is the fleet’s articulation.”
Chapters
Start here · a free chapter
11 · After the Factory
The pitch everyone’s heard — “idea to production in three days, two engineers, not twelve” — is real, on the first emit. The book asks the question nobody costs: and the next feature?
Read it free- Prologue — A Saturday Evening with a Broken Dashboard
- 1 The Two Cultures
- 2 The One Test That Survived the Migration
- 3 Bugs Grow the Blueprint
- 4 Seven Corners of Reliability
- 5 Same Product, Different Codebase
- 6 Build the Environment First
- 7 When You Can’t Run It Locally
- 8 The Frontend Blueprint
- 9 When the Codebase Stops Being the Moat
- 10 The Factory
- 11 After the Factory continued — The Bills
- 12 Which Moats Drain First
- 13 While You Were Out
- 14 Are You AI-Factory Ready?