Where People Actually Read Your Changelog

Think about the last time you learned that a tool you use had shipped something. You probably did not visit its changelog page that morning. More likely a small badge appeared inside the product, or a note landed in your inbox, or a bot posted in a Discord server you were already reading, or you saw the diff to CHANGELOG.md scroll past in a pull request. The changelog page existed, but it is not where the news reached you.

Writing a good changelog and getting anyone to read it are separate problems. KittyLog spends most of its engineering effort on the first problem. This post is about the second one, and about a small piece of self-inflicted marketing damage that taught me to take it seriously.

The card we had to replace

For a while, KittyLog's landing page had a three-card "distribution" section, and the middle card was RSS. Every public changelog gets a feed automatically, with autodiscovery, no setup. All true. Also, in 2026, completely unremarkable. Every changelog tool has RSS. Leading with it read less like a feature and more like an admission that we had nothing better to say.

The worse part is that we did have something better to say. The embeddable widget was fully shipped and live in repository settings, with a copy-paste script tag and a live preview, and it appeared nowhere on the landing page. Issue #1324 called this out plainly, and in July 2026 the RSS card was swapped for the widget card. RSS itself did not change at all; feeds and autodiscovery still work on every public page. What changed was the claim about which surface matters.

The reasoning behind that swap is worth spelling out, because it is really an argument about placement.

Match the surface to the reader

Different people learn about your changes in different rooms, and no single surface covers them.

Your users are inside your product. They are not going to check a hosted page on a schedule. The widget is a floating badge you drop into any website with one script tag; it shows an unread count and opens a panel with the latest entries, tracks last-seen in the reader's own browser, and follows light or dark theme. No build step, no framework. On the Free tier it carries KittyLog branding; from Plus up it is unbranded.

Developers live in the repository. For them the honest home of a changelog is a file under version control. KittyLog can open a pull request against your repo that keeps CHANGELOG.md current with every published entry, automatically if you turn the setting on. You review the PR like any other. (Tag-mode publishes can also land on the matching GitHub Release, a story that deserves its own post rather than a paragraph here.)

Subscribers asked to be told. These are the people who opted in, and they deserve a push rather than a place to poll. Discord notifications post each publish to a channel (Plus and up). Email digests shipped in July 2026, after issue #1071 pointed out that we covered feed readers and Discord but had no way for a reader to subscribe by plain email. Any reader can now subscribe from the public page, with double opt-in and one-click unsubscribe, and a digest goes out on each publish; the feature is on for Plus and up. And RSS is still there for the feed-reader crowd, on every tier, exactly as before. It just is not the headline anymore.

The hosted public page underneath all of this stays useful as the permanent record: the URL you link from support replies, the thing search engines index, the page a vanity link or custom domain points at. It is the archive, not the announcement.

The limit, stated plainly

There is a category of tool KittyLog is not, and it is easiest to see at the widget. Products like in-app notification suites identify individual users, segment them, target announcements per cohort, and price by monthly active users of the embed. That is a legitimate business, and KittyLog is not in it. KittyLog's widget has no per-user identity at all; the unread state lives in localStorage on the reader's machine, and we could not tell you which of your users opened it if we wanted to.

If you need per-user targeting, A/B-tested announcements, or an embed that doubles as a marketing channel with its own analytics, a dedicated widget host will serve you better, and I would rather say so here than have you find out after signing up. What KittyLog does is generate the changelog from your repository's actual history, let you review it before anything publishes, and then place it where each kind of reader already is: the app, the repo, the inbox. That is a narrower job than hosting high-volume embeds for everyone, and it is the one we chose.

Source records

• Issue #1324 and commit 5fb9bff6, the landing-page swap of the RSS card for the embeddable widget.
• Issues #1070 and #1063, the widget and the RSS / CHANGELOG.md round-trip marketing gap.
• Issue #1071 and PR #1345 (commit 6c82e11d), email digest subscribers.
• api/config/tiers.yaml, tier gating for the widget branding, Discord notifications, and email digests.