Your PRs write your changelog. Automatically.
Start new thread
Yash Bharadwaj

ShipLog - Stop shipping in silence.

by•
Connect your GitHub repository and automatically generate beautiful, user-facing changelogs from your merged pull requests. You can create a project, link your repos, and generate a changelog with just a click. It helps you maintain visibility on your work and reduces support tickets by showing users that you are actively shipping updates. The service provides a public changelog page, marketing site widget, and even sends weekly email digests to keep your users informed about the latest changes.

Add a comment

Replies

Best
Arnav Sawant
Maker
📌
Problem It Solves : Manual changelog creation is time-consuming and often leads to stale or forgotten updates, causing confusion among users about the status of a project. Solution : ShipLog automates the changelog generation process by reading merged pull requests from your GitHub repository and drafting the changelog for you. This saves time and ensures that your changelog is always up-to-date. What Makes It Unique : ShipLog uniquely combines AI technology with GitHub integration to provide a seamless and automated changelog experience, reducing overhead and improving visibility for users.
Jim Jeffers

I like the “PRs → user-facing changelog” direction. The hard part is usually not generating release notes, it’s deciding which engineering changes deserve customer-visible framing and which audience they matter to.

A feature I’d look for: a review step that labels each merged PR as user-visible / internal / bugfix / infrastructure, then drafts the update in benefit language instead of implementation language. That would make it much easier for small teams to turn shipping cadence into retention without creating noisy changelogs.

Arnav Sawant
Maker

@jim_jeffers yeah exactly ... that filtering layer is honestly the harder problem than generation itself

otherwise every changelog just becomes engineering noise 😭

we’ve been thinking a lot about:
“is this user-visible?”
“who actually cares about this update?”
“how do we frame this as value instead of implementation?”

really good insight, appreciate this

Jim Jeffers

@mrcybernaut That “engineering noise” line is the whole product problem. If you have one merged PR that produced a too-implementation-heavy changelog draft, I’d be happy to do a quick gut check: what should become user-visible value vs stay internal. One bullet/paragraph is enough.

Yash Bharadwaj
Maker

@jim_jeffers hey Jim, that's a great suggestion and we already have this implemented. Right now we are already ignoring/filtering out those pull requests which change internal files and are not adding anything meaningful to the product.
So only those pull requests which have meaningful change contribute to changelogs. In those changelogs also we have categories like Improvements, Fixes, Bugs..etc.
And before publishing user can always edit a changelog or change it's category, it's stored as a draft at first.