Favors.dev
The short answer
A changelog is a dated, running record of what changed in your product. It becomes a marketing channel when each entry is written around what the user gets, and when you rewrite the best entry each week for an email, a social post and a build-in-public update. You can do all of it from a markdown file on your own site, with no changelog tool.
Search for changelog advice and nearly every result is from a company that sells a changelog widget. They are not wrong, but they are answering a different question. If you are a solo founder with a text file and a deploy button, you do not need a widget. You need a habit and a way to reuse what you already wrote.
What does a changelog do that a blog does not?
It proves the product is alive, and it does it every time you ship. A blog post is a deliberate act that you have to find time and a topic for. A changelog entry is a by-product of work you already finished, so the cost is a couple of minutes.
That matters because a stranger deciding whether to try a small product is asking a quiet question: is anyone still looking after this? A changelog with entries from this month answers it better than any sentence on your landing page. One that stopped eight months ago answers it the other way.
It also solves the blank-page problem that sinks a shipping streak: the thing to share is already written down. The work is turning it into something a person outside your head can read.
What is the difference between a changelog, release notes and announcements?
A changelog is a dated, running list of changes, one entry per change, kept in one place. Release notes explain a version to the people using it, and an announcement makes one big change feel like news. The Keep a Changelog convention describes the first of these as a curated, chronologically ordered list of notable changes, and its main rule is that it is written for humans rather than machines.
| Type | Who reads it | Its job | Shape |
|---|---|---|---|
| Changelog | Anyone checking whether the product is alive, including you in a year | A dated, running record of what changed | One short entry per change, newest first, never deleted |
| Release notes | Existing users who want to know what a version means for them | Explain a bundle of changes by what they get | A summary per release, grouped by benefit |
| Announcement | Everyone who is not paying attention yet | Make one big change feel like news | A post, an email or a launch, written once per major change |
For a one-person product you do not need all three as separate things. Write the changelog entries well enough that they can double as release notes, and save announcements for the few changes that deserve one. If you are weighing a bigger moment, my guide to announcing a rebuild covers when a change graduates from an entry to an announcement.
How do you write changelog entries people actually read?
Lead with the outcome, then say how, then be honest about the limit. "Refactored the upload pipeline" tells a user nothing. "Uploads are about twice as fast, and large files no longer time out" tells them something they can feel. Keep this checklist beside the file:
- The first sentence says what the user can do now that they could not before.
- The second sentence says how, in plain words, with no internal names.
- One honest limit if there is one. It builds more trust than any adjective.
- A date on every entry, newest first, and nothing ever deleted.
- A link to the feature itself, or a short screen recording, when there is something to see.
- Bug fixes grouped into one short entry. Internal refactors left out.
A word on generating entries from commit messages. It is tempting, and it produces a record that is accurate and unreadable. Commits describe what you did to the code, and a changelog describes what happened to the user. Write the entry by hand, from the user's side.
The one-entry, four-channel loop
Here is the part that turns a record into a channel. You write one entry, then rewrite it for three more places, changing the reader each time and keeping the fact the same. The example below uses an invented invoicing app and an invented update, so you can see the rewriting and not a particular product.
1. The changelog entryAnyone who lands on your changelog
Receipts now file themselves. Snap a photo of a receipt in Tidybook and it tags the tax category and updates your books in about five seconds. It handles most printed receipts; handwritten ones still need a quick check.
Outcome first, then how, then the honest limit. This is the source text every other channel starts from.
2. The emailUsers who signed up and went quiet
Subject: Your receipts can file themselves now You used to type every receipt in by hand. Now you snap a photo and Tidybook tags the tax category for you. It takes about five seconds. Try it on the next one in your wallet.
One change, one sentence of why it matters to this reader, one thing to do. The entry's link goes at the bottom.
3. The social postPeople who have never heard of the product
Drop in a receipt photo. Tidybook files it, tags the tax category and updates your books in about five seconds.
Strip the product name from the first line and lead with the thing it does. A short screen recording does more than any wording.
4. The build-in-public updatePeople following the build
Shipped receipt capture today. The part that took longest was not the reading, it was deciding what to do when the photo is blurry. Handwritten receipts are still a manual check for now.
The one place the admission and the story belong. It reads as a progress note, not an ad.
The fact never changes: receipts file themselves in about five seconds, and handwritten ones still need a look. What changes is the reader. The entry speaks to someone checking on the product, the email to someone who drifted away, the social post to a stranger and the build-in-public update to someone following along.
That last channel is where the changelog connects to the habit in how to ship in public every day. The entry is the evidence, and the update is the story around it. If your social post needs polishing, the structures in how to write a launch tweet apply to a feature post as well.
Founders on Favors.dev already do part of this: each shipped thing can sit on the apps directory page for the product, so the update has somewhere visible to point besides your own site.
Can you do changelog marketing without a changelog tool?
Yes, and for a one-person product it is usually the better start. A markdown file in your repo, rendered as a page on your own domain, gives you three things a hosted widget does not: the entries live on your site, you control the wording and the layout, and there is nothing to log in to when you want to add a line.
If your code is on GitHub, the GitHub releases feature gives you dated, linkable entries with no extra setup, which works well for open-source and developer products. For everyone else, a simple page and an RSS feed are enough: the RSS specification is short, and a feed lets people who care follow the changelog without you doing anything.
Reach for a tool later, when you want an in-app "what's new" badge, per-segment announcements or a teammate writing entries. Until then the setup cost is the whole point, and it costs nothing, which is where marketing on no budget starts.
How often should you ship and publish?
Ship as often as the work allows, and publish on a rhythm you can keep. The record should be continuous and the promotion should be selective. If every entry gets an email and a thread, your readers learn to skip them.
Every time you shipAdd a one or two line entry to the changelog the same day.
Once a weekPick the best entry and push it through the email and social rewrites.
Once a monthPublish a short roundup of the month's entries as the real announcement.
Once a quarterReread the changelog and pull the three changes that moved a number into a longer post.
Look at an example of this done well. The Linear changelog is a dated list of shipped changes written around what users can now do, and it shows that a changelog can read like a product in motion instead of a log file. You do not need its design, only its habit of describing the user's side.
And keep the entries honest. If a feature ships half-finished, say so. A changelog that admits what is still rough is more believable than one where every line is a triumph, and that credibility is exactly what a small product is short of.
Frequently asked questions
What is changelog marketing?
Changelog marketing is using the record of what you shipped as a recurring marketing asset. Instead of treating the changelog as a technical archive, you write each entry so a user can see the benefit, then reuse that same text in an email, a social post and a build-in-public update. The changelog is the source, and the other channels are rewrites of it.
What is the difference between a changelog and release notes?
A changelog is a running, dated record of changes, one entry per change, kept in one place. Release notes explain a specific version to the people using it, grouped by what they gain. A small product can use the changelog as both, as long as each entry says what changed for the user rather than what changed in the code.
Do I need a changelog tool?
No. A page on your own site fed by a markdown file or a short list in your codebase is enough for a solo product, and it keeps the entries on your own domain where they can be found. A tool earns its place later, when you need in-app widgets, segmentation or a team writing entries. Early on, the habit matters more than the software.
How often should a small SaaS publish a changelog?
Write an entry whenever you ship something a user could notice, even if that is several times a week, and promote the best one weekly. Publishing every entry as a loud announcement trains people to ignore you, so keep the record continuous and the announcements occasional.
Should the changelog include bug fixes?
Yes, briefly. A line about a fix proves you read the report and acted on it, which builds trust with the person who sent it. Group small fixes into one entry, and leave out internal refactors that no user could ever see.