Most changelog advice is abstract. "Write for users." "Keep it short." "Be consistent." That's fine as far as it goes, but the most useful thing is seeing exactly what works in practice.
Here are ten real SaaS changelogs worth studying, with a breakdown of the specific thing each one does well that you can copy.
1. Linear: Clean, minimal, trust-building
What they do: Linear's changelog at linear.app/changelog uses a simple scrollable list with dates, short titles, and brief descriptions. Each entry is 2-5 sentences. There's a header image, a headline, and then prose. No categories, no tags, no noise.
What makes it work: It feels like it was written by a person, not a marketing team. The tone is direct and a little technical. For a product used by developers, that tone is exactly right. They don't oversell features. They just describe what changed and why.
What to steal: Match your tone to your audience. Developer tools should sound like developers wrote them. Consumer products should sound warm and accessible. Don't write your changelog in a different voice than the rest of your product.
2. Vercel: Short entries, consistent cadence
What they do: Vercel posts small changelogs frequently, sometimes multiple entries in a single week. Many entries are a single paragraph. They don't wait to batch everything into a big release. They publish as things ship.
What makes it work: The frequency signals activity. Even minor improvements feel like momentum because they're communicated immediately rather than held for a monthly roundup.
What to steal: Write the changelog entry the day the feature ships. Don't batch. The freshness matters.
3. Notion: Changelog as a product page
What they do: Notion's "What's New" pages at notion.so/releases are visually rich. Each entry has custom illustrations, clear structure, and a design quality that matches the product itself.
What makes it work: Notion cares about design, and their changelog reflects that. Every entry looks like it was designed specifically, not like a Markdown dump. For a product where design is a core value proposition, that's important.
What to steal: The changelog is part of your product's experience. If your product's strength is design/quality, your changelog should reflect that. Low-effort changelogs send a low-effort signal.
4. Figma: Linking updates to features directly
What they do: Figma's release notes link directly to documentation or tutorials for each new feature. "Read the docs →" or "Watch the tutorial →" appears alongside feature announcements.
What makes it work: The feature announcement and the usage guide are in the same workflow. Users who see a new feature and want to use it immediately don't have to go searching for how.
What to steal: Add one follow-up link per major feature. Either to your docs, or directly to the feature in the app. Remove friction between "I learned about this" and "I'm using this."
5. Superhuman: Changelog as delight
What they do: Superhuman's update emails and in-app announcements have a distinctive personality. They're short, enthusiastic without being performative, and often end with one-liners that match the brand's premium, opinionated voice.
What makes it work: The changelog reflects the brand promise. Superhuman promises to be the fastest email app. Their update communication is fast. Punchy. Gets out of your way. That coherence builds trust.
What to steal: Write in the same voice your product has. If your onboarding is warm and encouraging, your changelog should be too.
6. GitHub: Complete but scannable
What they do: GitHub's changelog posts very frequently, multiple times a week, with short, technical, precise entries. Each entry has a tag (API, Actions, Codespaces, etc.) and a one-line description.
What makes it work: With a product as large as GitHub, the tagging system is essential. Developers can filter for exactly what's relevant to them without reading through changes to parts of the product they don't use.
What to steal: If your product has distinct areas (billing, the API, a specific module), tag your changelog entries by area. Let users self-select into what matters to them.
7. Intercom: Changelog as marketing
What they do: Intercom's product updates are professionally produced. Video walkthroughs, polished screenshots, copy that emphasises the user outcome. Each entry reads like a mini product marketing page.
What makes it work: For a product where marketing is a core competency, this approach makes sense. The changelog is also a content channel for them, and entries get shared on social, linked from sales, forwarded internally by prospects.
What to steal: Your largest feature releases deserve more than a bullet point. For the 2-3 features per quarter that you're most proud of, write them up properly. A short paragraph, a screenshot, a video if you can manage it.
8. Basecamp / Hey: Changelog as personality expression
What they do: The HEY and Basecamp changelogs read like blog posts written by humans, not PR departments. Entries are in first person, share opinions, and aren't afraid to explain why a decision was made.
What makes it work: It's authentic. In a space full of corporatey update notifications, a changelog that sounds like a human wrote it stands out dramatically. People share them.
What to steal: Don't strip out the human. Explain the reasoning behind decisions occasionally. "We removed this feature because most users never used it and it was confusing the UI" is more interesting than "Improved UI." Share the why.
9. Loom: Eating their own cooking
What they do: Loom, a video messaging tool, has historically announced features using their own product: short Loom recordings alongside the text. Each entry lets you see the feature immediately without hunting for it in the product.
What makes it work: It's perfectly on-brand. A company selling video communication uses video to explain their product. The format also makes entries more useful than text alone.
What to steal: Use your product in your changelog where it makes sense. If you make screenshot tools, use screenshots. If you make design tools, design the entries. It's the most natural form of dogfooding.
10. Stripe: Technical depth as trust
What they do: Stripe's API changelog and product updates are deeply technical. Version numbers, deprecation notices, code examples. They don't dumb things down for a general audience.
What makes it work: Stripe's users are developers. Developers are turned off by vague, marketing-flavoured announcements. The technical precision is a trust signal. It says "we know who you are and we're talking to you directly."
What to steal: Know your user's technical literacy and match it. Writing for non-technical users? Be concrete and visual, not technical. Writing for developers? Be precise, specific, and complete. Never use technical jargon for a non-technical audience, and never dumb things down for a technical one.
The pattern across all of them
A few things every good changelog has in common:
- It's written for the reader, not the writer. The focus is on what changed for the user, not what the team did.
- It has a consistent voice. The tone never feels borrowed from a different product.
- It's posted at a predictable cadence. Users know to look for it.
- It links to more information when needed. It's the entry point, not the complete guide.
You don't need a design team or a marketing budget to do most of this. You need a clear understanding of who you're writing for and a commitment to publishing consistently.
If you're wondering how to actually get one running, this guide walks through adding a changelog to any web app in under 10 minutes, including the in-app widget setup that makes all of the above actually get seen.
If you want a changelog that can embed in your app, has a public SEO-friendly page, and takes 10 minutes to set up, Patchlog is free to start. You'll have something worth studying up and running before the end of your lunch break.