Software Growth

Changelog

A changelog is a dated, public list of what changed in your product. Done well, it informs customers, supports retention and gives you content to market.

A changelog is the running record of what you shipped and when: new features, improvements, fixes and removals. In open source, it is a file in the repository. In SaaS, it is a page on your site, often with an in-app widget, an RSS feed and an email digest. The same page serves two audiences: customers who want to know what changed, and prospects who want to know whether the product is alive.

The changelog vs release notes vs a blog post

  • Changelog: short, frequent, chronological, complete. Everything notable goes in.
  • Release notes: often the same thing for a numbered version, sometimes written in more detail for one big release.
  • Announcement post: a longer story for a major launch, with screenshots and context. The changelog entry links to it.

What the standard format says

The Keep a Changelog project defines a changelog as a curated, chronologically ordered list of notable changes for each version of a project. It is written for humans, not machines. Its principles carry over to SaaS:

  • Every release gets its own entry with a date.
  • The newest entry goes first.
  • Entries are grouped by type: Added, Changed, Deprecated, Removed, Fixed, Security.
  • Each version is linkable.
  • Keep an "Unreleased" section at the top so people can see what is coming.

Product teams usually rewrite those categories in friendlier words ("New", "Improved", "Fixed"), but the structure holds up. Always flag removals and deprecations clearly. Developers reading an API changelog need exact dates, endpoints and migration steps.

Why a changelog is also a marketing tool

A changelog is one of the few pages that existing customers, prospects and search engines all read. Its value comes from a few effects:

  • Trust. A page with entries every week or two shows buyers that someone is building, which matters when they compare you with a stale competitor.
  • Retention and adoption. A customer who asked for a feature and later sees it shipped feels heard. Teams use entries to drive feature adoption and to remind at-risk customers that the product keeps improving.
  • Content. Each entry can become a tweet, a LinkedIn post, an email to a segment or a line in a win-back campaign.
  • Search. Entries mention features by name, which can pick up long-tail searches.

ProductLift's roundup of changelog examples describes several patterns: minimalist timelines (Linear, Plausible), visual entries with screenshots and GIFs (Notion, Figma), developer-focused entries with version numbers and migration notes (Stripe, GitHub) and narrative entries framed around a problem and solution (Intercom, Slack). It recommends a consistent rhythm, benefit-led headlines and easy discovery through navigation and in-product widgets. Its claims about retention are the author's, not measured studies, so treat them as directional.

Enterprise angle

Larger customers care about change control. EnterpriseReady recommends detailed in-app changelogs linked to documentation, advance notice proportional to the size of the change, and feature flags so admins can decide when new features switch on for their users.

How to write entries people read

  1. Lead with the user benefit, then the detail. "Export invoices as PDF in bulk" beats "Added batch endpoint".
  2. Add a screenshot or a short GIF for anything visual.
  3. Name the plan if the feature is gated.
  4. Credit the request when a customer asked for it, with their permission.
  5. Skip the noise. Silent fixes do not need a line, but security and behavior changes do.

When a small SaaS should care

From the first public release. It costs a text file and 10 minutes a week, and it is easy to start. Put the link in your footer and in your onboarding emails. Pick a cadence you can keep, weekly or monthly, since an abandoned changelog with a last entry from eight months ago does more harm than none.

Related terms

Sources

Back to the SaaS glossary