ReleasePad
From git push to published release notes — zero manual work.
Quick launch story from ReleasePad, a changelog tool for small software teams.
The problem we keep hearing from customers isn't writing release notes. It's remembering to. The feature ships, the PR is merged, and the announcement sits on a to-do list until it stops mattering. Then users think the product went quiet, and support answers questions a two-line note would have covered.
A few months ago we noticed something in our own habits. We were already asking Claude and Cursor to summarize what we'd merged before writing a changelog entry. The AI did the writing fine. The friction was the copy-paste dance afterward: open ReleasePad, pick a category, paste, publish. So we asked the obvious question: why isn't the assistant just doing that part too?
That's what we shipped last week: a Model Context Protocol server for ReleasePad, live at pro.releasepad.io/mcp. If you use Claude, Cursor, Codex, or anything else that speaks MCP, you connect once through OAuth (no API keys to paste around) and your assistant gets a set of tools: list your categories, create a post, edit or reference earlier ones, upload images, schedule, and pull analytics on how posts performed.
A typical session now looks like: "Look at what we merged this week, draft a release note for customers, and leave it as a draft for me." Thirty seconds later there's a draft in ReleasePad, written in our tone, filed under Improvement, waiting for approval. Nothing goes out until a person presses publish. That was a deliberate line we didn't want to cross.
The part I find most interesting isn't the writing. Every changelog we host is also served as a Markdown feed that AI assistants can read. So the same kind of AI that helped build the feature now announces it, and the AI your customers ask about your product reads the announcement. The loop closes without anyone having to remember it.
Some things we learned building it:
- OAuth for MCP was more work than the tools themselves. Worth it. Nobody wants to paste an API key into a config file.
- Scoping matters. The assistant should be able to draft freely and publish only when told to. We made "draft" the default for every create call.
It's included in our Pro plan ($35 per product, flat, no seats). Free tier exists if you want to poke at the changelog first.
Genuinely curious: for those of you using coding agents daily, what other "last mile" tasks after merging do you wish the agent could just finish?
I noticed a weird problem while building software:
Teams ship improvements constantly, but users often have no idea.
A bug gets fixed.
A workflow gets improved.
A feature someone asked for finally goes live.
Then nothing happens.
No announcement. No changelog. No in-app notice. Maybe someone mentions it in Slack or replies to a support ticket, but most users never see it.
That feels like a huge missed opportunity.
Every uncommunicated update is basically a feature your users may never discover. And for small teams, changelogs are usually one of those “we should do this properly someday” tasks that keeps getting postponed because shipping the actual product feels more urgent.
So I started building ReleasePad.
The idea is simple:
You connect your GitHub repo, and ReleasePad turns your commits and PRs into user-friendly release notes using AI. Then it publishes them automatically to:
A hosted public changelog page
An in-app widget for your users
The goal is to make release communication happen as naturally as shipping code.
No manual writing.
No strict commit format.
No extra process for the team.
Just: ship code, and let ReleasePad tell users what changed.
I’m especially building this for solo founders, indie hackers, and small product teams who ship often but don’t have a dedicated product marketing person writing release notes every week.
I’d love feedback from other founders:
How do you currently tell users what changed in your product?
Do you write changelogs consistently, or does it become one of those “we’ll do it later” tasks?
-
1
Your post is sharper than your tagline, so trust the post. "Your users probably don't know half the things you've shipped" is the real product, and "git push to release notes, zero manual work" is just how it happens. Lead with the silence. But push the value one level deeper than discovery: an uncommunicated update is not only a missed feature, it is a missed proof-of-life. A user on the fence sees a changelog with twelve updates this month and thinks "this product is alive, my money is safe," and stays. That is why the in-app widget matters more than the public page, it reaches the user who was about to churn.
To your questions: almost nobody writes changelogs consistently, it is the permanent "later" task, and that is not a gap in your market, it is the whole market. Which means your wedge is not AI-generated notes, plenty of tools do that, it is zero process. The moment your product needs a commit format, a review step, or any discipline, the indie founder skips it exactly like they skip writing notes by hand. Your buyer is defined by "will never do this manually," so fully automatic, not AI-assisted, is the entire promise.
One question decides the page: do teams buy ReleasePad to stop writing changelogs, or to stop shipping into a void where users quietly assume the product is dead? Because the first is a chore-remover people skip, and the second is a retention tool people keep.
-
1
This is a real pain, especially for small teams that ship fast. Most founders think release notes are just “nice to have,” but they are actually part of activation and retention. If users do not notice what changed, the product can improve without the perceived value improving.
The sharper positioning may be less “AI changelog generator” and more “release communication layer for fast-shipping teams.” That gives you room to own the full workflow: GitHub input, user-friendly summaries, hosted changelog, in-app updates, and eventually segmentation by user type.
I would also pressure-test the name early. ReleasePad is clear, but it may keep the product boxed into release notes only. If this becomes a broader product communication layer, the brand may need to carry more than “release page.”
Xevoa .com would fit that direction well because it feels more like a workflow/product layer than a single changelog tool, while still leaving room for releases, updates, widgets, and user communication under one product brand.
Comment