Why we built ChangelogPilot instead of a better changelog editor
If you've got a GitHub repo and you ship regularly, you've probably had this conversation with yourself: "I should really post something about what shipped this week." Then Friday arrives, three things are on fire, and the changelog stays exactly where it was.
That gap — between how fast small teams ship and how rarely they tell anyone about it — is the whole reason ChangelogPilot exists.
The four things people actually do instead
When a team doesn't have a working changelog, it's usually not because they never tried. It's because one of four things happened.
They meant to write it themselves. Usually on a Friday. It takes thirty to sixty minutes of context-switching to remember what shipped and put it in customer language — exactly the time nobody has on the week something real is on fire. The intention was genuine. The habit never survived a busy week.
They tried a changelog tool. There are good ones — polished editors, embeddable widgets, hosted pages that look professional the moment you publish. All of that is real and useful. But every one of them still assumes the job is to write a good entry, and gives you a nicer place to do the writing. If the actual problem is that nobody has the twenty minutes, a nicer editor doesn't fix it — it just makes the twenty minutes slightly more pleasant to spend, on a week when nobody has them.
They kept a CHANGELOG.md in the repo. Zero cost, version-controlled,
lives right next to the code. Also: almost nobody outside engineering
reads a file in a GitHub repo. It's written in developer voice, for
developers, with no notification and no easy way for a customer to find
it.
They did nothing, and told themselves they'd get to it. The most common outcome, and the quietest kind of cost. Customers can't see the product moving even when it's moving fast. Perceived velocity flatlines while real velocity climbs — and that gap is where churn and "is this thing still maintained?" doubts creep in.
Our bet
Every one of those four paths treats writing as unavoidable — something to do faster, do more cheaply, or feel a bit guilty about skipping. We think the writing itself is the obstacle, and the honest fix is to remove it, not to streamline it.
ChangelogPilot reads your merged PRs directly. It drafts the entry, categorises it — feature, fix, improvement, breaking change — and leaves out anything that's purely internal. What's left for you is a decision, not a writing task: does this draft say what actually shipped? Approve it, edit it, or publish it as-is.
Who this is for
Small SaaS and dev-tool teams — roughly two to twenty people — who ship continuously on GitHub and don't have anyone whose job includes translating git history into customer updates. If you've already got a dedicated product marketer writing your release notes, you probably don't need us. If your changelog page hasn't moved in a few weeks and everyone on the team feels a bit guilty about it, that's exactly the gap we built this for.