Every SaaS ships improvements. Most of them die in silence.
You fix a bug that was costing a customer an hour a week. They never hear about it. You add an integration their team asked for three months ago. They're still building a workaround. You rename a field to remove the ambiguity that caused half your support tickets. The support tickets keep coming.
The product got better. The customer's experience of it didn't.
A changelog fixes this. It's one of the cheapest pieces of infrastructure a SaaS team can run, and one of the most under-built. This post is about why it matters and what makes one work in practice.
What a changelog is — and isn't
A changelog is a public, chronological log of what changed in your product. New features, fixes, breaking changes, deprecations, notable improvements. Dated. Written for humans. Discoverable from inside your app and outside it.
It is not:
- Release notes buried in a PDF. If your customer can't find it without a support ticket, it's not a changelog.
- A marketing blog. Those are for positioning. A changelog is for facts.
- Your git log. Nobody needs to know you bumped the React version. They need to know what they can do that they couldn't do yesterday.
- A Twitter thread. Threads disappear. A changelog is a durable artifact your users can come back to.
Think of it as a ledger. Every entry answers one question: what changed, and what can I do now that I couldn't do before?
The case for writing one
Four reasons, roughly in order of how much they matter.
1. It's how users learn what's new
Most users do not explore your UI on Thursdays looking for improvements. They come in, do the thing they came to do, and leave. If you shipped a better way to do that thing last week, they will not find it unless you tell them.
A changelog is the boring, reliable mechanism for telling them. An in-app widget surfaces it where they already are. An RSS feed reaches the ones who prefer their own reader. An email digest catches the ones who haven't logged in this week.
The point isn't that every user reads every entry. The point is that the entries are there, indexed, searchable, and referenceable — so when a user asks "has this been fixed?" they have a way to check that doesn't involve your support team.
2. It closes the loop on feedback
Users tell you things all the time. A quarter of it ends up as a shipped improvement. Some of it doesn't — and that's fine, but the quarter that does is a gift most SaaS teams don't use well.
A changelog entry that says "Added bulk export to CSV — requested by Acme Co." does three things at once:
- Tells the requester: you heard them.
- Tells everyone else: this is a team that ships what customers ask for.
- Gives your sales team a receipt for the next call where someone asks "do you ship fast?"
This compounds. Users who see their requests shipped ask for more. Prospects who see a steady log of shipped improvements trust you to keep shipping. Investors who ask about product velocity get a scroll instead of a deck.
3. It removes a class of support ticket
"Is X supported yet?" "When will Y be fixed?" "Did you change how Z works?"
If you are answering these in Intercom, you are a changelog waiting to be built. Every one of those tickets is a customer who wanted to self-serve and couldn't.
A public changelog, linked from your help docs and your empty states, converts a meaningful fraction of those tickets into a web search and a scroll. The ones it doesn't convert now have a reference you can link to in your reply — which is faster to write and more satisfying to receive than a one-off explanation.
4. It forces you to ship in units users recognize
This one is internal and underrated.
Writing the changelog entry is a decent forcing function for "is this actually ready to announce?" If you can't describe what changed in a sentence, you probably shipped a refactor, not a feature. If the best description involves three internal systems, you probably need to ship the user-facing wrapper first. If you're embarrassed to publish it, it's a hint to polish it before the first real customer hits it.
Teams that publish their changelog publicly write better features, on average. Not because the publishing improves the feature — because knowing you'll publish changes what you're willing to call done.
What makes a changelog work
Writing one is easy. Writing one users actually read takes discipline. A few rules that matter more than they look.
Short entries. Three sentences. A title, a one-line summary, an optional paragraph for context. If you need more, write a blog post and link to it.
Dated. Every entry gets a published date. Newest first. If it doesn't have a date, it's not a changelog entry, it's a feature page.
Categorized. Feature / fix / improvement / breaking / deprecated. Five categories maximum. Users scan by category more than by title.
Honest about breaking changes. If you broke something, say so, and say what to do about it. This is the single highest-trust signal a changelog sends. Teams that hide breaking changes get the reputation they earn.
Writable by the people who shipped the thing. If your changelog is bottlenecked on a marketer rewriting engineering prose, it will fall behind. The person who merged the PR should be able to publish the entry. Whether they write it from scratch, or use a CLI with --from-git and a model to draft it, is a workflow choice — but the bottleneck has to be small.
Here's what a good entry looks like:
## Bulk CSV export for team billing
*Feature · April 12, 2026*
Admins can now export the last 12 months of billing activity for their team
from **Settings → Billing → Export**. File includes invoice ID, amount, status,
and the seat count at the time of invoice. Requested by several teams doing
finance reconciliation — thanks for the nudge.
Ninety words. Dated. Categorized. Named the surface. Credited the request. That's the shape.
The anti-pattern: no changelog at all
The most common state of a SaaS changelog is that it doesn't exist. The second most common is that it exists, was updated for three weeks after launch, and hasn't been touched since. Both are worse than no changelog — the second is actively worse, because it signals "this team stopped shipping."
If you can't commit to publishing one, don't build one. If you can, treat it like any other customer-facing surface: it has uptime, it has quality, it has an owner.
The good news: the actual writing is an hour a week for most teams. The infrastructure is a script, a page, and an RSS feed. The discipline is the hard part — and the discipline gets easier the first time a customer emails to say they found the feature they needed in your changelog.
Where this breaks
A changelog is not a replacement for release announcements of major new capabilities, which deserve their own landing page, their own email, and their own support from marketing. It's also not a replacement for documentation — a changelog tells users what changed, not how to use it, and it should link out to docs for the how.
And it won't help a product that isn't shipping. If your changelog has one entry a quarter, the problem isn't the changelog. It's upstream of it, and a public log will just make it visible.
DeployLog is a changelog and release notes platform for developers. Post from the dashboard or the CLI, reach users through an embeddable widget, RSS, JSON, and email digests. Sign up with GitHub →