Let me be upfront about something embarrassing.
I've been running Geentoo — a platform for connecting project ideas with co-founders and collaborators — for almost two years. Real users, real features shipped, real bugs fixed.
And I have never written a changelog. Not once.
Not a release note. Not a "what's new" email. Not even a pinned post saying "hey, here's what changed this month." Nothing.
Why though?
It's not that I don't care about communicating with users. I do.
The problem is my git history. Here's a completely honest sample of what it looks like:
fix
wip
test
ok now it works
PLEASE work
final
final2
ok this is the real final
asdfgh
Sound familiar?
Every time I thought "I should write a changelog", I'd open the git log, stare at 300+ commits that looked like the above, and immediately feel exhausted. Then I'd close the terminal and go work on something else.
The gap between raw git history and readable release notes is enormous. You have to:
- Filter out the noise (CI runs, version bumps, merge commits, "fix" x47)
- Group related changes into something coherent
- Rewrite everything in plain language your users actually understand
- Do this for every release, forever
Nobody has time for that. So I just never did it.
Building the thing I needed
A few months ago I decided to stop feeling guilty about it and just automate it.
The idea was simple: connect to a git repo, pick two refs (a tag, a branch, a SHA — anything), fetch the commits in between, and use an LLM to generate structured release notes from them.
Simple in theory. A few interesting problems in practice.
The filtering problem
The first thing I learned: you can't just dump raw commits into an LLM and expect good output.
A typical commit range for a real project contains a lot of noise:
- Merge commits (
Merge branch 'feature/x' into main) - Version bumps (
chore: bump version to 2.3.1) - CI/CD commits (
ci: update pipeline config) - Dependency updates (
update lockfile) - And of course, the legendary
fix,wip,test
If you feed all of that to an LLM, you get bloated, incoherent output. Garbage in, garbage out.
So WhatShipped has a filtering layer that runs before the model ever sees anything. Noise commits are stripped out. Where available, PR titles are preferred over raw commit messages — they tend to be much more descriptive and intentional.
What reaches the LLM is a clean, curated list of meaningful changes.
The scale problem
Another real issue: large commit ranges.
If you're generating release notes covering 6 months of work, you might have 500+ commits even after filtering. That's too much to process in a single LLM call reliably.
WhatShipped chunks the commits and processes them in parallel, then merges the outputs into a single coherent document. This makes it reliable on large ranges without sacrificing speed.
The provider problem
I didn't want to be locked into one LLM provider, and I suspected users wouldn't either.
WhatShipped supports both Claude (Anthropic) and OpenAI. You choose which one generates your notes. Same filtering pipeline, same output format — just different models under the hood.
Dogfooding it immediately
The first thing I did when the tool was working was run Geentoo's commit history through it.
Two years of wip and fix and ok this is the real final — turned into structured, readable release notes with sections for new features, bug fixes, and performance improvements.
It worked. Actually worked, on a real messy project, not a clean toy repo.
That was the moment I felt confident enough to call it a product.
The business model
I didn't want to build another subscription SaaS that charges $20/month for something you might use twice.
WhatShipped runs on credits. 1 credit = 1 generation. You buy what you need, when you need it.
New accounts get 1 free credit on signup — no card required. Try it on real repos and see if it's useful before spending anything.
What it looks like today
- Connects to GitHub, GitLab and Bitbucket
- Pick any two git refs as your range
- Outputs clean Markdown — ready to paste into your changelog, README, or release page
- Works on messy real-world histories, not just clean conventional commits
You can try it at whatshipped.dev.
What I'm looking for
I'm at the very beginning of this. The product is live, the core flow works, and I'm now focused on getting real users and real feedback.
If you've ever skipped writing a changelog because your git history was too messy — I'd genuinely love for you to try it and tell me what you think. What's missing, what's confusing, what would make it actually useful for your workflow.
Every piece of feedback right now is worth more than any feature I could build.
Thanks for reading 🙏
Top comments (0)