Why we don't ship a changelog-as-marketing
What the build log is, and what it isn't.
Most software companies treat their changelog as a marketing channel. New features rendered in animated GIFs, copy that promises a transformation it can't deliver, a screenshot of a Slack reaction thread for credibility. The thing they ship and the thing they advertise are the same thing, which is convenient until they aren't.
Our build log is the other thing — the one engineers actually keep. Date, project, message, status. The same line that gets read in standup. We don't embellish quiet weeks and we don't suppress messy ones, because the build log is the artifact, not the marketing.
The rule we keep
If a line wouldn't survive a standup, it doesn't go in. That's most of the editing. It's also the only editing.
The downside is that some weeks the log just says “Pilot expanded — third operator onboarded” and that's the entire entry. The upside is that when we say a thing shipped, the receipt is two clicks away.
What gets a line
- A version that left the building, not one that's “ready to demo.”
- A bug fix that ate more than a day or that we owe somebody an explanation for.
- A primitive crossing into stable. Not when we wrote it; when we trusted it.
- A note when a quarter ends without a notable line. Quiet weeks are quiet weeks.
What doesn't
- Internal refactors that nobody outside our standup will ever feel.
- Marketing copy dressed as a release.
- Roadmap items that haven't shipped yet. Roadmaps go on the product pages.
The log on the home page is the same one the studio reads. It's short on purpose. If you're evaluating whether we're a real shop, that's the receipt.