Our story

For six years I was CTO at a sales-analytics startup. We shipped constantly — real improvements, most weeks — and we were never good at telling our customers about it. There was always something that looked more urgent than writing the update, so the update didn't get written.

That prioritisation felt reasonable at the time. It was wrong. Telling customers that a product is evolving isn't housekeeping — it's part of the product. Every improvement you actually communicate compounds the faith a customer already placed in you; it's the difference between "the thing I bought" and "a team that keeps making the thing I bought better." It also draws people back in: a note that something new has landed can catch a customer who was halfway out the door and turn them into someone who tells other people about you. We under-invested in that for years, and I don't think we were unusual.

Why it was hard

The reason isn't that teams don't care. It's that the work of turning "here's what merged this week" into something a customer would actually read is genuinely time-consuming, and it lands on people who already have a full plate. In the pre-AI world there was no good shortcut: summarising changes well was a human job done under time pressure, and it usually came out thin — or didn't come out at all.

Why now

That's the part that finally changed. Large language models got good enough to read a merged pull request and produce a genuine, customer- facing summary of what changed — close enough to approve rather than rewrite. Not long ago this was either a manual effort with poor results, or needed models too costly to train and run to be worth it. The technology has caught up to the problem. That timing is the whole reason ChangelogPilot makes sense now and didn't a few years ago.

What I set out to build

I didn't want a nicer editor for the update nobody has time to write. I wanted the writing gone. ChangelogPilot connects to a GitHub repo, drafts each changelog entry from what actually merged, and hands it back for a decision — not a writing session. The job drops from "write a changelog" to "approve a draft."

It's built for small teams — bootstrapped and early-stage SaaS and developer-tool companies, roughly two to twenty people — because that's where the gap between shipping speed and telling-people speed is widest, and where nobody's job is to close it.

Why small, on purpose

ChangelogPilot is built and run by a small team in New Zealand, and it's bootstrapped by choice. I have a strong belief in small software teams: software is a craft, not a factory, and it doesn't have to hyperscale to be worth building. Bootstrapping keeps us honest — because we can't defer profit the way venture-funded companies do, the features stay focused and the decisions stay intentional. That's not a constraint we're apologising for; it's the point.

The day-to-day building here — a good share of the code, the copy, the routine decisions — runs through AI agents that I direct. I want to be straight about that, and equally straight that it isn't where the product came from: ChangelogPilot is built on 25-plus years of engineering practice, across tech-consulting leadership and startups, with the same review and testing discipline any serious team uses. I set the direction and make the calls that need judgment; the agents do a lot of the execution under that discipline. It's an operating model, not a shortcut around building the thing properly.

Where things stand

We're early stage — working through real repos with real, sometimes messy PR histories rather than clean demo data. If the "shipped the work, never sent the update" pattern sounds familiar, connect a repo, or get in touch.