Kaiju Tracks
Measured, not remembered.

Notes on stewardship, tradeoffs, and what building with AI actually costs.

I build and run a portfolio of products where the large majority of the production work is done by AI agents rather than by me. This is what that does to the decisions — written from the commit record rather than from memory, and the reasoning is mine.

Subscribe — it’s free Read the archive →

Roughly weekly. One decision or one incident per piece, evidence attached, never more than about 10 minutes to read. No paywall, no upsell.

The record so far

11,941commits in the record
63.9%carry a machine co-author
41weeks with recorded activity
6repositories, one portfolio

Computed from the commit log when this page was built, 11 August 2026 — not typed in and left to go stale. Covers August 2025 to August 2026; weeks with no commits are omitted, so the count above is weeks of activity within a 50-week span, not an unbroken run.

The contract

I publish the parts where I was wrong.

Most writing about building with AI is written from memory, shortly after something impressive happened. This is written from the record. Every factual claim traces to a commit, a file diff, or a dated artifact — and when the data contradicts something I’ve published here, that gets said in the same piece rather than the next one.

One of the early pieces is about how I accumulated 19,000 lines of test coverage in two days, felt very good about it, then quietly let the suites covering my three highest-traffic screens sit disabled for three months — finding out by accident, four days before the thing reached a single user.

Anyone can write the version where the tooling is remarkable and the author is prescient. That version is worthless to you, because you can’t tell it from a version that’s made up.

The corresponding ask: if I get something wrong, tell me. I’d rather be corrected than agreed with.

What this isn’t

Who this is for

People making these decisions rather than reading about them. Product leaders and founders working out what changes operationally, not just what becomes possible. If you’re responsible for what a team can deliver next quarter and you’re trying to separate real leverage from the appearance of it, we’re looking at the same problem.

Start here

Who’s writing

Twenty years across product and engineering, most of it spent responsible for outcomes rather than output. Until July 2026 I was Chief Product Officer at SignUpGenius, where I built the product function from the ground up and helped drive 14x revenue growth across SaaS, advertising and payments for a platform serving 70M+ users.

I got there by way of engineering, and I’ve been starting companies the whole time — including an aftermarket auto parts business I grew past 40,000 SKUs and sold in 2011, which is most of the explanation for why one of the products here is an automotive app.

Why any of that matters: I know what normal looks like. I’ve run the planning cycles, owned the consequences of being wrong about capacity, and sat through enough technology cycles to be suspicious of my own enthusiasm. When I tell you something changed, I have a baseline to measure it against.

Subscribe

Free, and it stays free. Unsubscribe in one click.