What a changelog is, why it's worth the ten minutes it takes, and the smallest version that's still worth publishing.
A changelog is a running list of what changed in your product, in the order it shipped. That's the whole definition. Everything else — categories, formatting, whether it's public or internal — is a choice about who you're writing it for.
It's easy to assume a changelog is something you add once you have a support team, or a few thousand users. In practice, the earlier you start, the cheaper it is. Three things it buys you almost immediately:
You don't need categories, visibility rules, or a design system on day one. The minimum viable changelog is a dated list of one-line, plain-English entries — no jargon, no PR numbers, no internal ticket references. If a non-technical user of your product couldn't understand the entry, it's not ready to publish yet.
Skip the blank page
Buoylog drafts changelog entries from the GitHub PRs you merge — you just review and publish.
Start free trial →As a changelog grows, a few things usually get added, roughly in this order: categories (so a reader can scan for what matters to them), a way to keep some entries out of the public page (security fixes, internal notes), an email or in-app way to reach people who won't visit the page on their own, and eventually a way to keep translations or scheduling separate from the day-to-day writing. None of it needs to exist before you publish your first entry — it's fine to add it when the plain list stops being enough.
Not lack of features — inconsistency. A changelog that goes quiet for three months and then dumps twenty entries at once reads as neglect, even if the underlying product shipped constantly. The habit of publishing matters more than the polish of any single entry.