chrisscho.uk
[ FIELD NOTE ]claude-codeengineeringcompound-engineering

1,570 Commits, £0 Revenue. The Most Valuable Thing I Built Wasn't the Product.

The product I've spent the most hours on this year has made no money. I want to get that out of the way early, because it changes what the rest of this post is actually about. If I'm honest about the revenue, I have to be honest about what I actually got for the time: the system I built to build it, more than the product itself.

The problem with starting cold

Every AI coding session used to start from nothing. I'd explain the architecture again. I'd re-discover a gotcha I'd already hit three months earlier, because nothing had written it down where the next session could find it. The model was getting better every few months. My sessions weren't, because they had no memory between them.

The fix turned out to be three files and two hooks, small enough to describe in a paragraph, that turned every session into one that starts a little smarter than the last.

Diagram of the compound engineering loop: a session start hook loads MEMORY.md and vault context, the session references instincts.md while working, a session end hook writes new instincts back to MEMORY.md and the vault, and the loop repeats.
Three files, two hooks, one loop. Each session leaves the next one a little smarter.

The three files

MEMORY.md is short on purpose, a couple of hundred lines, loaded automatically at the start of every session. Architecture decisions, known gotchas, where the business actually stands right now. Not a wiki. A briefing document, rewritten often enough that it never goes stale, because staying short means there's nowhere for the stale parts to hide.

instincts.md is the part that actually compounds. Confidence-scored engineering patterns, over a hundred and sixty of them by now, each one born from something that actually happened rather than something I read. An instinct starts life Emerging, the first time a pattern shows up. It gets promoted to Strong once it's saved real time a second time, in a different context. It becomes Proven once it starts catching problems before they happen, rather than explaining them after they did.

One instinct I keep coming back to: never subquery a particular table inside a row-level security policy, because the two interact in a way that recurses and quietly kills performance. First time, I found it the hard way and wrote it down as Emerging. The second time, in a different table with the same shape, the instinct caught it before I'd finished writing the query. That's the whole idea in one example: the second occurrence didn't cost an afternoon, because the first one had already been paid for and filed away.

The vault is where the business thinking lives, alongside the vault's own private research and day-to-day notes that never need to reach the codebase at all. It's git-synced and structured so an agent can actually read it, rather than being a pile of prose a human has to summarise first.

The two hooks

A session starts, and /start loads MEMORY.md and the relevant slice of the vault before I've typed a single instruction. A session ends, and /done writes back: any new instinct that earned its place, any decision worth remembering, an update to MEMORY.md if the business state actually moved. Nothing compounds if the writing-back step gets skipped, which is the part I still occasionally skip when I'm in a hurry, and regret within about a week.

Why honesty was the harder engineering problem

The instinct I'd rank above all hundred and sixty of the others has nothing to do with code: being straightforwardly honest about a limitation, in a commit message, in a README, in a client-facing report, builds more trust than being right does. Being right is table stakes and nobody remembers it. Being the one who said "this doesn't work yet, here's why" is the thing people actually come back to.

That instinct is harder to hold onto than any RLS gotcha, because the pull toward sounding confident is constant and the reward for it is immediate. This whole post is an attempt to apply it: the product made no money, the coordination layer I was proud of got deleted two months after I built it, and none of that is hidden in what you've just read.

What actually compounded

Not the codebase. Codebases rot, get rewritten, get replaced by better tools. What compounded was the judgement, a hundred and sixty specific things I now know that I didn't a year ago, each one attached to the exact moment it was earned rather than floating free as a vague sense that I've "gotten better at this." Judgement like that doesn't show up in a diff. It shows up in how much less often the same mistake gets made twice.

Eighteen months in, the honest tally is a product with no revenue and a stack of hard-won, confidence-scored judgement that makes every session after this one faster than it would otherwise have been. I'd have said, at the start, that the product was the point and the system was scaffolding around it. I don't think that anymore. The scaffolding's the part that's still standing.

Want systems like this in your business? See consulting services →