Release notes and changelog

Turn this on and shipping starts producing its own marketing: Ballad reads what you released, drops what a customer would never notice, and writes a note that names only what actually changed.

The setup is a four-step walkthrough in your Inbox — Set up release notes — and it ends with your first note written.

1. Name the product

Three fields: the product's name, what it does in a sentence, and where people find it. Everything Ballad writes about releases is held to them, which is what stops a release note inventing a feature name that doesn't exist.

If you sell more than one thing, each product keeps its own changelog, its own intake and its own secret.

2. Where the changelog lives

Same choice as your blog, and for the same reason — it belongs on your domain:

• My site, by itself. The changelog is a collection your site renders through the content API. With the Next.js package it's one more call beside your blog, with its own path and feed. See Set up your Next.js blog.
• My own changelog, by hand. Ballad writes the entry; you paste it wherever your changelog already lives and hand back the URL.

This site's changelog is the first kind: entries drafted by Ballad from what shipped in the app, approved by a person, rendered by our own site.

3. How releases reach Ballad

Four doors, and you can use more than one:

Door	What it's for
GitHub releases	A webhook on release events. Ballad takes the tag, title and body; the version decides the size.
Commits	A webhook on push. Nothing is drafted at intake — commits pile up and are digested on a cadence.
An agent	Claude, or anything with an agent key, reporting a release as it happens.
By hand	A dialog where you write what shipped in a sentence.

The walkthrough shows you the payload URL and the secret for each webhook, with a copy button. Point GitHub at it, paste the secret into the webhook's own secret field, and you're done.

Commits are the interesting one. Set a cadence — daily or weekly — and when it's due, Ballad reads the commits since the last digest, drops the refactors, test fixes and dependency bumps, groups the rest into changes described as what they let a customer do, sizes the release, and drafts the entry. A week where nothing user-facing shipped produces nothing.

You can also backfill: Ballad walks your history in the same buckets and writes one back-dated entry per period, each published at the date it actually happened, so a new changelog doesn't start empty.

4. From notes to a launch week

A release note is the smallest thing Ballad does with a release. When something major ships, it proposes a launch week: the changelog entry, founder posts on each network you've connected, a thread, a brand post, the newsletter issue, a Show HN and an image card — each pinned to a day, in the voice that should say it.

You trim what you don't want, pick the start date, and approve the week once. Every piece still comes to you for review before it goes out, and the whole week is measured together: reach, clicks and signups rolled up as one launch rather than scattered across five dashboards.

What it never does

• It doesn't name a feature you didn't ship, or claim a number you didn't give it.
• It doesn't write a founder anecdote about a launch that didn't happen.
• It doesn't publish the entry before you approve it.

Next

• Set up your Next.js blog — render the changelog on your domain.
• Social media — the posts that carry a launch.
• Connect Claude to Ballad — report releases from an agent.