The spec-first turn
Months of writing instead of coding: the entire product on paper before a line was built.
After the eleven quiet weeks, work resumed in October 2025, but not in a codebase. In a documentation repo.
What it was. The whole product, written down before building: what it’s for, who it serves, what every screen shows, how every flow behaves, what the AI is allowed to do at each step (twelve canonical documents, vision, PRD, personas, information architecture, user flows, a software requirements spec, LLM system specs, domain model, API spec, design system). Alongside the documents, the product’s shape emerged: a “workbench” built around the CODE method (Capture, Organize, Distill, Execute) every thought passing through the same four stations.
What went wrong. Nothing, yet. The specs were good, and writing them worked exactly as hoped. But they quietly encoded the idea that would later prove wrong: that one pipeline could process any thought. You can watch the doubt surface in the commit history: months of redesigning the same two screens over and over (endless card-based reworks of the Distill and Execute workbenches, then a “chat-first” pivot), trying to make a rigid machine feel natural. When a design keeps getting redesigned, the problem is usually underneath the design.
What I decided. Build the specced product for real, in TypeScript, in a fresh organisation: specs imported, lessons attached.
Next era: v2: the wrong machine