Build a changelog effortlessly

Most changelogs die the same way. Someone sets up a page, writes three beautifully formatted entries, and then stops — not because they stopped shipping, but because the changelog was a second job bolted onto the end of the first one. Six months later the newest entry is from March and the page quietly becomes evidence that nothing is happening.

There are two separate problems in that story, and they need different fixes.

Problem one: writing it is a separate chore

The entry gets written in a different tool, at a different time, from the work it describes. By the time you sit down to write it, you have to reconstruct what you did — which is why it turns into "various bug fixes and improvements", which is worse than nothing.

The fix is to write it where the work finished. If the feature came from a request on your feedback board, marking that request Done offers you a changelog entry with the title already filled in and the category mapped to a tag. You are editing a draft, not facing a blank page.

Entries are markdown, so there is nothing to learn:

Imports now handle files over 50MB. Previously anything larger timed out
silently at the upload step — it now streams, and shows progress.

- CSV and TSV both supported
- Existing rows are matched on email, not row order

Tag it New, Improved or Fixed, and publish. Or save it as a draft and let three of them accumulate until Friday — drafts are invisible until you publish, so there is no cost to writing one the moment the work lands.

Problem two: nobody reads it

This is the half that actually kills changelogs. Writing entries nobody sees is demoralising in a way that no amount of discipline survives, and a page people have to remember to visit is a page nobody visits.

So publishing an entry should be publishing it everywhere, once:

• A public page at feedfa.st/p/your-project — the URL you link from your footer and paste into a support reply
• An RSS feed at /p/your-project/rss.xml — how the handful of people who care most, and every aggregator, will follow you
• An embedded widget in your own product, either inline in a page or as a floating "What's new" badge with an unread dot

The badge is the one that changes the numbers. It puts the entry in front of people already using the product, at the moment they are using it, and the unread dot clears itself once they look. That state lives in their own browser — there is no list to manage.

<script src="https://feedfa.st/embed.js" data-project="your-project" defer></script>

That is the badge. If you would rather place things yourself, add data-badge="false" and drop entries wherever you want them:

<div data-feedfast="changelog" data-variant="card" data-limit="3"></div>

Cadence beats completeness

You do not need to write an entry for every merge. A changelog that records every dependency bump is as unread as one that records nothing.

A reasonable rule: publish when something would change what a user does. A new capability, a fixed annoyance, a removed limit. If nothing crossed that bar in three weeks, that is fine — the page is not a productivity dashboard and nobody is counting.

What is worth being strict about is not letting a shipped thing go unannounced for a month. The value of the entry decays fast, and the person who asked for it has already concluded you did not do it.

When you would rather not open the dashboard

If writing the entry in a browser is the friction, remove the browser. There is a REST API with scoped keys, and an MCP server that lets an AI agent publish for you:

Publish a changelog entry for the CSV import fix we just shipped

The MCP server is a client of the same public API — it holds no database connection, so a read-only key stays read-only through an agent exactly as it would through curl. It reads your board and your uptime too, which makes "summarise what shipped this month" a question you can ask rather than a document you assemble.

The short version

• Write the entry when the work finishes, not on changelog day
• Convert Done requests instead of starting from blank
• Describe what the user will notice, not what you changed
• Publish once and let the page, the feed and the widget do the distribution
• Skip weeks where nothing crossed the bar

Two follow-ons, if this is the problem you are solving: which tool to actually pick, and why the date on your newest entry is the most load-bearing number on your site.

Effortless is the wrong word for anything you have to remember. The point is to make it small enough, and connected enough to the work, that remembering is not required.