Say what shipped in the first line, then tell one thing that happened while you built it: what you got wrong, what surprised you, or what a user told you. End with what’s next. That’s the whole post. The changelog tells people what the feature does; the LinkedIn post is where you say why it was worth building.

This guide is for a post from your own account, as the person who built or shipped it. A company page announcement is a different job, closer to release notes.

What should go in the post?

Four things, usually in this order:

  1. What shipped. The feature’s name, in plain words. “We shipped CSV import this week.”
  2. Why it matters. Who asked for it, or what people can do now that they couldn’t before. A number helps: how many requests, how long it took.
  3. The one story. Something that happened while building it. This is the part only you can write, and the part people remember.
  4. What’s next. The next feature, or an invitation to try it. One line.

Leave out the full feature list. Link to the changelog or docs if people need it.

What does a good version look like?

Here are four lines of notes about a real kind of launch:

Shipped CSV import this week
- most requested feature, 3 weeks of work
- almost built it wrong: users wanted mapping, not upload
- next: Google Sheets sync

The third line is the story. “Users wanted mapping, not upload” turns an announcement into something another builder can learn from: people name a solution when they ask for a feature, and the need is one step underneath.

We gave these notes to Claude Opus 5.5 with a journalist persona. This is what it wrote:

We shipped CSV import this week.

It was our most requested feature, and it took three weeks. That is not the part worth telling.

The part worth telling is that we almost built the wrong thing. People kept asking for “CSV import,” so we started on upload. Upload was never the problem. Getting a file into the product is easy. Getting their columns to land in the right fields is where the work was. What users wanted was mapping.

The request named the feature. It did not describe the need. We caught the difference before it shipped, which is the only reason this is a short post and not a postmortem.

Next up is Google Sheets sync. We will be asking what people mean by that before we write a line of it.

About 700 characters. Every fact in it comes from the four lines of notes. The same notes with the Builder persona open with “CSV import is live 🎉” and go into more detail; pick the voice that sounds like you.

What should you cut?

  • “Thrilled to announce.” Start with the news itself.
  • A thank-you list. Thank the team in one sentence, or tag them. A long list pushes the story below the “see more” cut.
  • Every feature at once. One post, one story. If you shipped three things, the other two can wait for their own posts.
  • A lesson that repeats the story. If the story made the point, you don’t need a paragraph explaining it.
  • Hashtag blocks. Two or three, if any.

For more on why AI drafts fall into the same shape and how to edit them out, see Why Do AI LinkedIn Posts All Sound the Same?.

Can AI write it from my pull request?

For X, yes: give the model the pull request and ask for a launch post. For LinkedIn, write your notes by hand first. A pull request tells the model what changed, but not the story behind it, and the story is what makes a LinkedIn post worth reading. Paste the PR description in with your notes if you want the details right, and put your own view in the notes.

Where StashBase helps

If you post about every release, keep the notes, past posts and changelogs in one folder. In StashBase, our free, local-first writing workspace, Claude Code, Codex or Antigravity can read that folder beside the draft: last month’s post for your voice, the changelog for the facts, your notes for the story. You write the post in the same place you keep what it’s built from.