Writing a SaaS Changelog That Users Actually Read

Most SaaS changelogs read like release notes for an internal build system. "v2.14.3 — improved caching layer." Users see one and close the tab. The changelogs that get read look completely different — they sound like a human, come out on a regular cadence, and treat users as people, not release consumers.

This is the version of writing a SaaS changelog that we've seen work across different products. Not the format — the mindset. Format follows once the mindset is right.

Why most changelogs are ignored

Three reasons, in the order they hurt.

Too technical. "Refactored the auth flow" tells users nothing about what changed for them. They don't know or care what auth is.

Too frequent. Publishing every micro-fix trains users to ignore the changelog. It becomes noise before it becomes signal.

Too infrequent. Publishing every three months means users have already forgotten the last set of changes. Momentum resets each time.

The changelogs that work are somewhere in the middle — weekly or biweekly — and they translate every entry from engineering language to user language.

The three-line entry format

The format that consistently gets read has three lines per entry.

Line 1: what changed, in the user's language. Not "shipped feature X" — "you can now [do specific thing]."

Line 2: why it matters to them. One sentence about the situation this helps with.

Line 3: how to try it. A link, a location, or a one-line instruction.

Everything longer than three lines fights the "read time under 60 seconds" reality of a changelog. Users scan; the format should serve scanning.

The tone that works

Changelogs written by product teams almost universally sound corporate. Changelogs that get read sound like a specific person talking.

Use "we" and "you." Use contractions. Skip the marketing verbs. Say "we fixed a bug" instead of "resolved a known issue impacting a subset of users." Users respond to voice; there's no reason a changelog can't have one.

Look at Linear's changelog, Cron's, Attio's, Vercel's. Different products, similar tone. Not by accident.

Cadence

The most successful cadence for small SaaS teams is weekly, published on the same day of the week. Predictability is half of what gets users back.

Biweekly works if the shipping pace is slow. Monthly is where users start forgetting the product exists between updates. Quarterly is where changelogs go to die.

Even in a slow week, publishing something small — a bug fix, a small refinement, a preview of what's coming — keeps the rhythm alive. Skipping a week is fine occasionally. Skipping four in a row is where the discipline breaks.

What to include, and what to skip

Everything a user might notice, translated into their language.

Include

• New features, even small ones.
• Improvements to existing features that users will feel.
• Bug fixes for issues users complained about publicly.
• Performance improvements users will notice.
• Design refreshes.

Skip

• Internal refactors that don't change user behavior.
• Backend infrastructure changes.
• Bug fixes for issues nobody was hitting.
• Anything you'd have to explain the acronym for.

The rule of thumb: if a user wouldn't feel it, wouldn't ask about it, and wouldn't Google it, it doesn't belong in the changelog.

Screenshots and short video

A screenshot per major feature is worth more than four paragraphs of explanation. A 10-second Loom recording is worth even more.

Not every entry needs media. Reserve it for the changes that actually benefit from being seen. Text plus a good screenshot is the format Linear popularized, and it holds up for a reason.

Where to publish

Three places, in order of value.

A dedicated page on your site

/changelog or /whats-new, indexable by search engines. Every entry is a URL. Users can bookmark, share, and find historical entries. This is the base.

Email digest

A short email at the same weekly cadence, sent to opted-in users. Not every user reads emails; the ones who do value them. Our post on transactional email covers the deliverability side.

In-app notification

A small "what's new" indicator inside the product. Users see it when they log in. Keep it small and dismissible — it should never block the actual work they came to do.

Twitter and LinkedIn are amplification, not distribution. The changelog page is the source of truth; social shares link back to it.

Tools that help — and don't overshoot

Purpose-built changelog tools exist. Whether you need one depends on team size.

For solo founders and tiny teams

A Markdown file in your repo rendered as a route on your site. Zero cost, full control, git history built in.

For small teams

Same, but with a slightly nicer surface. Some teams use Ghost, Notion, or a simple headless CMS. Anything that lets non-engineers publish without a code deploy.

For teams that want more

Canny, Featurebase, Frill, or LaunchNotes. They combine changelogs with feature request boards. Worth it once you have significant user request volume; overkill before then.

Best practices we've seen work

Write in first person plural, present tense. "We added…" reads better than "was added" or "the team has released…"

Lead with the biggest change. Users scan; put the important item first, small stuff below.

End with a one-liner about what's coming next. Keeps momentum, gives users something to look forward to. Just a sentence, not a roadmap.

Show gratitude for reports. When a bug fix comes from user feedback, say so. Users who see their reports show up in the changelog file more reports.

What not to do

Don't publish only when big features ship. Users lose the habit of reading between events. The weekly rhythm is the value.

Don't publish everything on Notion pages that require sign-in. Changelogs need to be indexable and shareable. Public URLs, not walled gardens.

Don't use version numbers as titles. Nobody except you knows what "v3.14" changed.

Don't try to be funny in every entry. One or two lines of personality per changelog is charming. Every line trying to be witty is exhausting.

Trade-offs

Writing a good changelog takes 30 to 60 minutes a week. That's real time for a small team. The trade is that changelogs consistently rank among the highest-signal marketing channels a small SaaS can run — cheaper than ads, more durable than tweets.

The other trade is momentum. Once users get used to a weekly rhythm, missing weeks costs trust. The habit compounds; interrupting it costs more than starting it.

Frequently asked questions

Final take

A changelog is the most read piece of writing a SaaS produces, after the pricing page and the homepage. It deserves the same care those pages get. Translate to user language, publish on a rhythm, keep the tone human, and users will come back to see what shipped.

If you're setting up a changelog or reworking one that isn't landing, book a call. We'll help shape the format and cadence to match your product.