For a long time my changelog was a commit history and a vague memory. I shipped things every week, and the people who asked for them mostly never found out.
That is a waste. The cheapest marketing a small product has is telling the person who asked for a feature that it is done.
Why a changelog matters more when you are small
Big companies have release emails, product marketers and launch weeks. I have a changelog.
A public changelog does three jobs for a solo developer:
- It proves the product is alive. A visitor deciding whether to trust a tiny SaaS looks for signs that someone is still working on it. A list of dated, shipped changes answers that faster than any landing page copy.
- It closes the feedback loop. Someone took the time to request a feature or report a bug. When it ships, they should hear about it. Otherwise they stop asking.
- It keeps me honest. If the changelog is empty for a month, I notice.
The problem is that a changelog in a separate tool becomes one more thing to update, and it drifts away from the requests it is supposed to answer.
Keep the changelog next to the requests
In Pullwish the changelog lives on the same project as the feedback board and the public roadmap. A changelog entry can be linked to the feature request or bug it closes, so the story is in one place: someone asked, people voted, it moved through the roadmap, it shipped, and the entry says what changed.
An entry has a short summary, and optionally a longer description and a version. You can keep an entry as a draft and publish it when the release is actually out. Entries can also stand on their own without a linked request, for the things nobody asked for but you shipped anyway.
One detail I care about: if a feature is marked internal, its changelog entry stays off the public changelog too. So I can track private work in the same project without it leaking into the public list.
Write the entry from your editor
I build in Cursor, and I wrote about triaging feature requests from inside Cursor with MCP recently. The same hosted MCP server has a publish_changelog tool.
So the end of my loop looks like this: the agent and I finish the feature, I ask it to publish a changelog entry for that request with a one-line summary, and it does — without me opening the dashboard. The summary is still mine to approve. I do not want an AI writing release notes I have not read.
Tell people where they already are
Most users will never go looking for a changelog on their own, so I put it where they already are: on the same public board where they requested the feature and voted on it. Pullwish's own changelog is the Changelog tab on our board: https://www.pullwish.com/projects/iGBUmKRzcovPHJAP1Z6Y
Show it inside your own app
If you want a "What's new" list in your own product, the public API has GET /changelog. It returns published entries for your project, with a limit and offset for paging, and it leaves out entries linked to internal features.
Pricing — be honest
The public roadmap and changelog are on the free Hobby plan: one project, customer voting, roadmap, changelog and comment threads, no card.
Writing changelog entries through the hosted MCP, and reading the changelog through the API, need API access. Hobby has no API access, so those parts need Indie or higher (€19/month, VAT included where applicable). New accounts get Indie free for 14 days with no card. Details: https://www.pullwish.com/#pricing
What this is not
A changelog does not write itself here. Someone still has to decide what is worth telling users and say it in plain words. Pullwish keeps the entry next to the request and gets it to your users; the words are yours.
If you want to see how it fits together, try the live demo from the menu on pullwish.com — no sign-up needed.
AI Disclaimer: This article was drafted with AI assistance from my own notes on how I use Pullwish. I reviewed, edited and fact-checked it against the product before publishing.