I Built a Changelog Tool Because I Was Too Busy Shipping to Write One

I've been a developer long enough to know that the hardest part of shipping isn't the code.

It's the sentence after.

"What did you build today?"

Shepherd — Where It Started

My first real taste of this problem was at Shepherd, where I joined as a founding engineer.

The team was early, fast-moving, fully remote. And like most early-stage teams, we had a system for staying aligned: a Discord server. Every day, in the dev channel, everyone was expected to drop a summary of what they'd done. What they'd shipped. What was moving.

Simple enough on paper.

In practice, I'd find myself at the end of a ten-hour day, brain completely empty, staring at a blinking cursor in a Discord message box. I'd spent the day deep in the codebase — real work, good work — and now I had to explain it in plain language to people who needed to understand it quickly.

So I'd do the thing. Open the terminal. git log. Read back through a day's worth of commits that I'd written in thirty-second bursts between moments of deep focus, and try to reconstruct something coherent from them.

Most of the time I'd produce something technically accurate and almost entirely unhelpful.

"Fixed auth issue. Updated user endpoints. Refactored session logic."

Fine. True. Useless to anyone trying to understand the actual state of the product.

I kept thinking: there has to be a better way to do this.

Then Came Rootz

A few months later, I got a DM on X.

A founder — I'll keep his name out of it — had an idea for a file sharing platform built specifically for big publishers. The kind of infrastructure that lets media companies move large files fast, without the chaos of Dropbox links in email chains. He had the vision. He didn't code. He needed someone who could build the whole thing.

That person was me.

So I became the fullstack engineer at Rootz. Solo at first — which meant I was the backend, the frontend, the architecture decisions, the deployment pipeline, everything. When you're the only technical person on a team, the work moves at whatever speed you can sustain.

For a while, the documentation problem almost didn't matter. There was no one else to document for. I knew what I'd built because I'd built all of it.

Then we brought on a frontend developer.

The Moment the Problem Became Real

The day a new developer joins a project you've been building alone is a specific kind of reckoning.

Suddenly all the context that lived only in your head needs to live somewhere else. Every architectural decision you made at 2AM needs an explanation. Every module that "makes sense if you know why I built it that way" needs actual documentation.

As the lead, I was responsible for that. For onboarding him properly. For making sure he could move without constantly asking me what things were for.

And beyond the internal documentation — we had users. Real ones. Publishers who were depending on Rootz for their workflows. When we shipped updates, they needed to know what changed. Not in commit-message language. In language that made sense to someone who ran a media company, not someone who read diffs for fun.

So now I had two problems at once.

Changelogs for the team — so the new dev knew what we'd built and why. And announcements for users — so our publishers understood what was changing in the product they depended on.

Both of them required the same thing: taking what lived in the git history and translating it into something human.

And I was still the one doing that translation, manually, imperfectly, usually late at night after I'd already spent a full day building.

The 1AM Realization

I remember the specific night it clicked.

We'd just had a big sprint. Lots of changes across the platform — some new file handling logic, some UI updates on the publisher dashboard, a few API fixes that had been on the list for weeks. Good work. The kind of week that felt productive.

Now I had to write it up. For the new dev. For our users. For the internal record.

I opened git log. Twenty-three commits. Written across five days, in small bursts, most of them carrying only enough context for me-in-the-moment.

I stared at this for a while.

And then I thought something that felt almost embarrassingly obvious once it occurred to me:

Everything I need is already here. I just can't read it fast enough.

Not in the commit messages — those were basically useless. But the actual diffs. The files that changed. The lines that moved. The whole record of what happened, preserved perfectly, right there in the repository.

The problem wasn't information. The problem was that translating twenty commits of raw code changes into coherent human language — at 1AM, days after writing them — was genuinely hard work. And I kept doing it slightly wrong.

But that translation problem? That's exactly what AI is good at.

That Thought Became ShipLog

I started building it for myself. Not as a product — just as a tool to get my Friday evenings back.

Connect it to GitHub. Point it at a commit range. Let it read not just the messages but the actual diffs — what changed in which file, what was added, what was removed. Send all of that to a language model with a prompt that said: write the changelog a thoughtful lead engineer would write if they had time to do it properly.

The first time it worked, I sent it to our frontend dev instead of my usual vague summary.

He replied within ten minutes: "This is actually really helpful. I finally understand what the storage refactor was doing."

That was the moment I knew it wasn't just a personal tool.

What ShipLog Does

It's simple. You connect your repo, select a range of commits, and ShipLog reads the real code changes — not just the messages, but the diffs. It understands what actually moved in your codebase, and it writes the version of that story your users, your team, or your manager can actually understand.

No more 1AM archaeology. No more vague summaries. No more showing up to standup and saying "uh, a lot of backend stuff" when you shipped something real.

If you're a solo dev, a founding engineer, or a lead who suddenly has teammates to document for — this is for you.

Start free — 5 changelogs a month, no credit card.

I built Rootz nights and weekends and wondered why the communication part was harder than the code.

Turns out it wasn't supposed to be this hard. It just needed the right tool.