Your users probably don’t know half the things you’ve shipped
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?
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.
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.