How to add a changelog to any web app with one script tag

You ship all the time. A fix here, a new setting there, a feature you spent a whole weekend on. And your users mostly don’t notice.

That gap is expensive. When people can’t see a product moving, it feels abandoned, even when you’re shipping every week. They churn a little faster, they email asking for things you built a month ago, and all the momentum you’re actually creating stays invisible.

The fix is boring and old: a changelog. But not a changelog rotting in a Notion doc nobody opens. One that shows up inside your app, where users already are.

Here’s the approach I settled on.

The idea: a widget, not just a page

A “what’s new” widget is a small button or badge in your UI. Click it, and a panel slides out with your latest updates. Users see it in the flow of using your product, not on some /changelog page they’d never visit.

You really want three things:

1. An in-app widget users actually see.
2. A public page and RSS feed you can link from emails and docs.
3. A way to write updates in plain language and publish in a click.

The one-tag version

I ended up building a tool for this (honest disclosure below), but the integration is the part worth showing, because it’s the pattern any changelog widget should follow:

One script tag. No SDK, no npm install, no framework coupling. It behaves the same in React, Vue, Rails, or a plain HTML page.

Two implementation details matter, whether you build one of these yourself or evaluate an existing one:

• Render it in a Shadow DOM. A changelog widget should not inherit or leak styles. If it uses the host page’s global CSS, it will look broken on half the sites it lands on. Shadow DOM isolates it completely.
• Fail silently. A marketing widget must never break the host app. If the network call fails, it should quietly do nothing.

What to actually write in it

The tool is the easy part. The discipline is writing updates people care about. A few things that have worked for me:

• Tag each entry as New, Fixed, or Improved. People scan, so give them anchors.
• Write like a person. “CSV exports were timing out on big accounts, now fixed” beats “Resolved asynchronous export latency regression.”
• Ship small and often. Ten small updates read as momentum. One giant quarterly post reads as a company that went quiet for three months.
• Schedule them. Write the note when you ship the code, set it to publish later, and your changelog stays alive even in a busy week.

Honest disclosure

I build Patchlog, so the snippet above is my own tool. I’m not going to pretend otherwise. It’s early: the free tier is one project and 25 updates, which is genuinely what I run on my own projects. I’m sharing the approach because it’s helped me, and if it saves you the afternoon it cost me to think through, great.

The actual point

Whatever you use, whether you build it, use mine, or use a competitor, close the gap between shipping and your users noticing you shipped. That gap is quietly costing you retention, and it’s one of the cheapest things in your entire product to fix.

What do you use for changelogs today? Always curious how other people handle this.