How to embed a public changelog in your SaaS product

If your users do not know what changed, they assume nothing changed. A public changelog fixes that. The hard part is not writing the entries. The hard part is plumbing the publishing flow so it actually keeps up with your release cadence.

This guide shows the cleanest setup for a small SaaS team.

The three pieces you need

A changelog system has three parts.

1. A place to write entries (Markdown, Notion, or an admin panel).

2. A public page that shows them.

3. A way to surface new entries inside your product (an in app widget or a notification dot).

Most teams hand roll all three. The result is usually a Markdown file on GitHub Pages, a custom admin endpoint, and a half built widget that breaks when the layout changes.

A better path is to use a dedicated changelog tool that gives you all three out of the box and exposes an API so you can publish from your CI pipeline.

Step 1: Create a changelog account

Sign up at https://changelog.dranco.uk. The free tier gives you one changelog with a public URL like https://changelog.dranco.uk/c/yourcompany.

You will get an API key in your inbox.

Step 2: Publish entries from your release pipeline

This is where most changelogs die. People mean to write one when they ship a feature. Then they ship the feature, the meeting happens, the changelog never gets written.

Solve it by automating publishing as part of your release.

GitHub Actions example:

name: Publish changelog entry

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Send to changelog
        run: |
          curl -X POST https://changelog.dranco.uk/api/entries \
            -H "X-API-Key: ${{secrets.CHANGELOG_API_KEY }}" \
            -H "Content-Type: application/json" \
            -d '{
              "title": "${{github.event.release.name }}",
              "content": ${{toJSON(github.event.release.body) }},
              "version": "${{github.event.release.tag_name }}",
              "type": "feature"
            }'

Now every time you cut a GitHub release, the body becomes a published changelog entry. No human writes the entry separately. You get one source of truth.

Step 3: Embed the widget in your app

Drop a single script tag in your app shell.

<script
  src="https://changelog.dranco.uk/widget.js"
  data-changelog="yourcompany"
  data-trigger=".changelog-button"
  async></script>

Then add a button anywhere in your UI with the class changelog-button. The widget pops a panel of recent entries when the user clicks. Auto includes a notification dot when there are unread entries.

Step 4: Offer an RSS feed

Every changelog gets an RSS feed at https://changelog.dranco.uk/c/yourcompany/rss. Power users will subscribe in Slack channels, in Feedly, in their own internal tooling.

Link it from your changelog footer. Half a line of HTML.

Why not just write Markdown to a repo

The Markdown file approach works for the first ten entries. Then you discover:

• The widget you wanted to embed needs HTML, not Markdown
• RSS needs separate generation
• Filtering by type (feature/fix/breaking) needs separate metadata
• Pagination breaks at 50 entries
• Search is impossible
• You have rebuilt the changelog tool, badly

Three months of part time work to rebuild something you could have wired in twenty minutes.

What good changelog entries look like

Independent of the tool, good entries do three things.

They name the user benefit, not the feature. "Dark mode now follows your system preference" beats "Implemented theme detection logic."

They explain why. A one line context sentence turns a release note into a story. "Customers asked for this so often we just shipped it."

They link to the docs. Every entry should link to either the relevant doc page or the support article. Otherwise you get the same support ticket five times.

What it costs

changelog.dranco.uk is free for one changelog. £9/mo for ten changelogs with custom branding. Headway charges $29/mo for the same surface.

Bottom line

A public changelog is the cheapest piece of marketing your engineering team can ship. It tells your users you are alive. It gives sales something to point at. It compounds over time as your entry history becomes evidence that you actually ship.

Sign up at https://changelog.dranco.uk and wire it into your CI before lunch.