One founder on X put it bluntly: "The changelog is the last thing anyone writes." Features ship, the team moves on, and the release notes either never appear or appear weeks later as a vague list.
That is a missed opportunity. A SaaS changelog page is one of the few places a product can show, with dates, that it is improving. Customers check it to see whether the bug they reported is fixed. Prospects check it to see whether the product is maintained. One sales-focused post on X described every feature you ship next month as "a deal you get to reopen". This guide covers how to build a changelog page people actually read and how to keep it up.
Why a changelog matters after launch
After launch, the questions people ask about your product change. Before, it was "what does it do?" After, it becomes:
- Is this product still being worked on?
- Did they fix the problem I reported?
- Is anything about to break my integration?
- What is new since I last looked?
A dated, regular changelog answers all four. It is also useful to your own team. Support can link to an entry instead of writing the same explanation repeatedly. Sales can point a hesitant prospect to the feature they asked about. Your team gets a record of what shipped and when.
What every entry needs
Keep entries consistent so readers know what to expect. Each one should have:
- A date. The single most important detail. Undated entries undermine the whole page.
- A short title that says what changed, such as "Export reports to CSV", not "Version 2.4.1".
- A tag for the type of change (more on this below).
- One to three sentences explaining what changed and who it affects.
- A link to documentation, if the change needs explaining in more depth.
- An image or short clip, for visual changes, if it helps.
Version numbers are fine to include, but most customers do not think in version numbers. Lead with the change.
Tags: feature, fix, improvement, breaking change
Tagging entries lets different readers find what they care about. A simple set covers most products:
- Feature: something new that customers can use.
- Improvement: something existing that works better.
- Fix: a bug resolved.
- Breaking change: something that requires customers to act, such as an API change.
Breaking changes deserve special care. Give them a clear label, explain what customers need to do and by when, and link to a migration guide. Developers who rely on your product will look specifically for these.
Let visitors filter by tag. Someone checking for breaking changes before an upgrade should not have to read every minor fix.
Writing entries people read
Most changelog entries are written for the team that built the feature, not the people who will use it. A few habits help:
- Write from the customer's side. "You can now schedule reports to send every Monday" is better than "Added cron support to report service".
- Say why it matters, briefly. One sentence on what problem it solves.
- Keep it short. If it needs more than a paragraph, link to the docs.
- Credit requests, where appropriate. "Many of you asked for this" lets customers know they were heard.
- Be honest about fixes. Say what was wrong in plain terms.
Some teams now draft release notes from their commit history or pull requests with AI tools and then edit them by hand. One founder on X described cutting the time spent from 45 minutes to under 10. Whatever method you use, a person should read every entry before it goes out.
Where the changelog sits: docs, pricing and blog
A changelog works best as part of a small set of pages that a product needs after launch:
- Docs, so customers can learn how to use what you shipped.
- Changelog, so they can see what changed.
- Pricing, so prospects can see what it costs.
- Blog, for longer explanations, announcements and stories.
These pages link to each other. A changelog entry links to the relevant docs section. A blog post about a major release links to the changelog. When these pages are scattered across different tools with different designs, customers have to work harder to find things.
Link to the changelog from your main navigation or footer, and from inside your product if you can.
Keeping it up without a developer
The main reason changelogs go stale is that updating them takes too much effort. If adding an entry means asking a developer to edit a page, it will slip behind.
The fix is to make each entry a piece of content added through a form: date, title, tag, text, link. Anyone on the team, whether a product manager, a support lead or a founder, can publish an entry in a few minutes.
Set a rhythm as well. Weekly or every release, whichever suits your pace. A changelog with regular small entries reads as more alive than one with a big update every few months.
Setting up Refrain
Refrain is a Framer template for a software product after launch. It puts docs, changelog and pricing on one site.
The changelog runs on the CMS. Every release is dated and tagged as a feature, fix, improvement or breaking change, and visitors can filter by tag. Shipping an entry means filling in a form, not editing a page. The docs page has section navigation covering introduction, first request, authentication, errors, pagination, rate limits, webhooks and migrating. Pricing has tiers and a comparison table edited on the canvas, and a CMS blog, a get started page and a setup guide are included.
Every text layer uses a named text style and every colour uses a colour style, 38 in total, so changing one updates the whole site. It has desktop, tablet and phone layouts with a real mobile menu, and costs $79 with one licence covering unlimited sites.
If you also need product, security and book-a-demo pages for a technical buyer, Switchyard includes a changelog alongside those. Read can you blog in Framer? for how the CMS handles posts, and see Framer templates for SaaS for more.
The changelog will probably never be the most exciting page on your site. Kept up, it is one of the most convincing.