Shipped But Silent: A Vibe Project Guide to Changelogs and Release Communication

Last Wednesday night, your coding agent fixed 14 bugs, shipped 3 features, and casually refactored your entire settings page. Thursday morning you open the app store, and the "What's New" section reads: Bug fixes and performance improvements. You stare at that line the way you'd stare at a report card that says "satisfactory progress" — zero information, zero emotional value.

This is the endemic disease of vibe-coded projects: you shipped, but nobody knows. AI lets you cut three releases a day, yet the number of releases your users actually perceive is zero. The widening gap between shipping speed and perceived speed is quietly eating your retention — users don't leave because you stopped shipping; they leave because they think you stopped shipping.

This guide is the full playbook for closing that gap: a changelog is not a git log for developers, it's product storytelling. It doesn't answer "what code changed" — it answers "why is this product worth opening again this week." Below: picking your conventions, the art of versioning, channel-specific messaging, writing templates, public roadmaps, copy-pasteable code, and a release SOP.

Why Vibe Projects Need Changelogs More Than Anyone

A traditional team ships monthly and a changelog is a nice touch. A vibe project ships five times a week — without a changelog, that's a disaster. Four reasons, each more practical than the last.

First, the trust deficit: AI-written code starts with one extra strike against it

Users don't know or care whether AI wrote your code, but they can feel that "this product changes really fast." Rapid change with no explanation triggers instinctive unease: a button moved yesterday, an API response changed today. A changelog is you telling users "every change is under control" — every explanation is a deposit in the trust account. Shipping silently is a withdrawal machine.

Second, perceived speed drives retention, not shipping speed

Do the math: you shipped 20 improvements this week, users perceived 0, so 90% of the week's work was wasted. When indie developers complain "I built so many features but users never come back," the truth is usually that users never knew those features existed. A changelog is the cheapest channel for translating "shipped" into "noticed" — cheaper than ads, faster than blogging.

Third, it's your marketing asset library

Product Hunt launch posts, update threads on X, version announcements on your newsletter — all the material comes from one place: a well-written changelog. Linear's changelogs get shared around; Raycast's release notes ship with GIFs that spread on their own. Good changelogs come first, good launch marketing second — don't reverse the order. Launch marketing without a changelog is improv; quality depends entirely on how you feel that day.

Fourth, you're writing to yourself three months from now

Vibe projects have an invisible reader: future you. The code AI generates in a day would take you a month to hand-write. Three months later, when you wonder "why was this weird compatibility hack added," the git log says fix: resolve edge case in export flow — which says nothing. A user-facing changelog doubles as a product decision memo.

One-line test: if you shipped three releases last week and your users can't name a single thing you changed, you don't have a feature problem — you have a changelog problem.

Picking Your Conventions: Keep a Changelog × Conventional Commits

First, separate two things people constantly confuse: Conventional Commits is a commit convention for collaborators (and tools); Keep a Changelog is a changelog convention for users. One governs input, the other governs output. The most common mistake in solo vibe projects is doing only the former — tidy commits, empty changelog.

Keep a Changelog: six drawers in the user's language

Keep a Changelog sorts every release into six categories, and the names themselves are user-centric:

• Added: new features — things users can directly touch
• Changed: behavior changes to existing features
• Deprecated: going away soon, consider this a heads-up
• Removed: features that are gone
• Fixed: bugs squashed
• Security: security fixes, broken out separately to reassure users

Notice what's deliberately missing: "optimization," "refactor," "misc." Users don't care that you refactored state management; they care that "it opens faster now." Any change that can't be translated into a user benefit doesn't belong in the changelog — the git log is fine for it.

Conventional Commits: a machine-readable commit dialect

feat: xxx, fix: xxx, docs:, refactor:, chore:, and the BREAKING CHANGE: footer. The value isn't that it "looks neat" — it's that tools can read it: git-cliff and release-please can assemble a changelog draft straight from commit history, routing feat into Added, fix into Fixed, and auto-flagging anything with BREAKING CHANGE.

My field-tested advice: have your agent write commits in Conventional Commits (one system prompt does it), and always rewrite the changelog by hand. Tool-generated drafts are "developer dialect"; users need plain human language. Automation solves "from zero to one"; human rewriting solves "from one to good." Skip neither step.

The selection matrix: what to use at what scale

• Solo side project, weekly releases at most: a hand-written CHANGELOG.md following Keep a Changelog is enough. Conventional Commits is optional — just get your agent into the feat/fix prefix habit; it costs almost nothing.
• Solo full-time product with a fixed biweekly release: enforce Conventional Commits + auto-generate drafts with git-cliff + rewrite by hand. The best bang-for-buck combo — about 20 extra minutes a week.
• Small team / open source / external API consumers: the full release-please pipeline — commits drive version numbers, auto-tagging, auto-drafted GitHub Releases. At this point the changelog is a contract; there's no room for sloppiness.

The decision rule is one line: could your change break someone else's code? If yes, use the strictest tier. If no, a hand-written Keep a Changelog is plenty. Don't adopt conventions for the sake of conventions — in vibe projects, conventions exist to save time, not to be worshipped.

Two prompts for your agent: make conventions automatic

Conventions in vibe projects can't rely on "remembering" — they have to live in prompts. Drop these two blocks into your agent's system prompt or project-level AGENTS.md, and conventions go from "manual checklist" to "default behavior":

[Commit convention]
Commit after each independent change. Messages MUST use Conventional Commits:
- feat: user-visible new features; fix: bug fixes; refactor: no behavior change
- docs: documentation; chore: dependencies/build misc
- Breaking changes MUST add a blank line + BREAKING CHANGE: describing impact
- Write in English, one line, max 72 chars; never "update" or "fix bug"

/* Changelog draft */
Before each release, draft CHANGELOG.md from this batch of commits:
- Include only user-perceivable changes; refactors/dependency bumps stay out
- Use Added / Changed / Fixed / Security categories
- One sentence per entry, start with a verb, say where users can see it
- Mark the draft [DRAFT]; I will rewrite it by hand before publishing

Note the last line of the second block — "I will rewrite it by hand" — the most important line in the whole pipeline. Agent output is always a draft; only a human presses publish. The changelog is your product's face; don't hand the last mile of automation your face.

Semantic Versioning in Practice: The Honest Art of the 0.x Era

Everyone can recite SemVer (semver.org): MAJOR.MINOR.PATCH — breaking changes bump MAJOR, new features bump MINOR, bug fixes bump PATCH. But vibe projects spend 90% of their lives in 0.x, and the 0.x rule is a single sentence: anything MAY change. That sentence is both a shield and a trap.

0.x is not a get-out-of-jail-free card; it's an honesty contract

Many treat 0.x as a license to break things without accountability: "it's 0.x, anything may change, users can't complain." That's the worst possible reading of SemVer. What 0.x really means is: you're still in rapid experimentation — but experimenting doesn't mean going silent. The honest approach is the opposite — document every breaking change in the 0.x era, because your early users are your most valuable asset and deserve to be treated seriously.

In practice I recommend the "0.x trio":

• Version numbers still matter: even moving fast, keep 0.8.1 and 0.9.0 distinguishable. Don't be the project stuck on 0.1.0 forever. Version numbers are a safety gauge for users.
• Breaking changes still get migration notes: even three lines — an old-vs-new (before/after) snippet. When Tailwind CSS v4 shipped (January 2025), they wrote every breaking change as a before/after table and shipped an @tailwindcss/upgrade auto-migration tool. They're at 4.0 and still that considerate — what's your excuse at 0.x?
• Set a "graduation line" for 0.x: e.g., "no breaking changes to the API for three straight months" or "100 paying users," then go 1.0. 1.0 doesn't mean "perfect" — it means "I'm ready to promise."

Three signals you're ready for 1.0

• Someone pays for your product — payment is the strongest stability commitment; 1.0 is your answer to paying users;
• Someone builds on your API/plugin ecosystem — now a breaking change costs "someone else's business," not just "user annoyance";
• You haven't wanted to rewrite the core module for two straight months — the architecture has settled.

The anti-pattern is the project parked at 0.9.9 for three years: afraid to go 1.0 is just afraid to promise. Users can smell that hesitation.

How to communicate breaking changes without getting flamed

The verdict first: breaking changes get flamed not because you changed something, but because you didn't warn, didn't provide an escape hatch, and didn't speak human. Four pieces, all required:

• Warn ahead (deprecation period): mark it Deprecated at least one version early, with warnings in the console/UI. The migration time you give users equals the reputation you keep.
• Provide an escape hatch: ship a migration tool when you can (codemods, auto-upgrade scripts); when you can't, commit to a clear "old version supported until X date." "Just upgrade, it's incompatible" is the most flame-bait phrasing there is.
• Speak human: not "refactored the auth middleware for OAuth 2.1 compliance" but "login is changing: old API keys work until Dec 31, then switch to OAuth login — 3 steps, docs here."
• Offer compensation: when breaking changes hit paying users, an extra week of trial or a month's discount costs almost nothing and works wonders. Users don't want money — they want to feel taken seriously.

A cautionary tale: a well-known open-source project (naming no names) quietly changed a default config in a minor release, breaking production for droves of users — 400+ furious issues. The maintainer's response: "it was in the docs." In the docs ≠ communicated. Flag it under a big Changed header in the changelog and half the anger evaporates.

The Release Channel Matrix: One Changelog, Four Ways to Tell It

The same changelog needs different scripts for different channels. Many indie developers write only a GitHub Release and then complain "nobody reads it" — well, your users don't live on GitHub. The matrix principle: let the user's attention context decide the information density.

In-app update modal: the 3-second rule

A user seeing a popup has at most 3 seconds of patience. Say three things: one sentence on the biggest change, one image (screenshot/GIF of the new feature), one button ("Try it" / "Got it"). The modal always features only the sexiest item from Added; the rest lives behind "View full changelog." Raycast is the benchmark here: every update modal is one sentence plus one GIF, with the full changelog one click away.

Script example: "PDF export is finally here →" with a screenshot of the export menu. Never write "we're excited to announce" — nobody's excited except you.

Email update digest: monthly or per release

Email is the only channel users actually archive, so it can carry a bit more. Subject formula: version + the single most attractive item, e.g., "v2.4: dark mode is here, plus 12 fixes." Body structure is fixed: 1 opening line → 3–5 curated updates (one sentence + link each) → 1 teaser for next time. On cadence: a meaty biweekly email beats a watery weekly one — unsubscribe rate is the only true judge; above 1% means you're sending spam.

X vs. newsletter/blog: one does memes, the other does stories

The easiest pair to mix up. On X you have peers and geeks — go technical, go meme: "cut PDF render time from 8s to 0.4s by swapping Chromium for…" with a code screenshot; geeks eat that up. On your newsletter or blog you have regular users — talk scenarios: "month-end expenses: export a full month of receipts to PDF in 3 minutes," with an animated demo. Same update: X explains "how we did it," the newsletter explains "what it does for you." Never ship one draft to both.

Product Hunt / Show HN comment threads: the "thread within the thread"

After launch day, your own comment thread becomes your second changelog. Periodically replying to your Product Hunt post or Show HN thread with "What's new since launch" is the cheapest re-exposure there is — every reply pushes the thread back into some subscribers' feeds. The key move: thank the people who suggested things (actually @ them) and tie their suggestion to what you shipped: "you asked for PDF export last time — it's in this release." That's the shortest path from critic to evangelist.

GitHub Releases: the complete edition for developers

This is the one place "developer dialect" is fine: the full Added/Changed/Fixed list, migration code for breaking changes, and the contributor list (@ them — genuine social currency). If your project has API consumers, add an "upgrade checklist" too. GitHub has offered "Automatically generated release notes" since 2021 — use it as a draft, never publish it raw; PR titles are written for reviewers, not users.

Writing Templates: Good vs. Bad for Three Entry Types

The gap between good and bad changelogs isn't prose style — it's information architecture. The universal formula first: start with a verb + user perspective + scope of impact + call to action. Below, one good-vs-bad pair per category; the bad ones are all real-world phrasings (including my own early work).

Features (Added)

❌ Bad: "Added export functionality." — Export what? Where? What does it do for me? Fails all four questions.

✅ Good: "Report pages can now export to PDF: top-right → Export → PDF, and the template automatically inherits your current theme colors. Exports include bookmarked outlines — they print beautifully too." — verb-first ("can now export"), user perspective (report page, top-right), scope (theme colors, bookmarks), action (three-step flow).

Fixes (Fixed)

❌ Bad: "Fixed known issues and improved stability." — the zombie phrasing littering every app store. The only thing users learn: you didn't want to tell them what you fixed.

✅ Good: "Fixed the date picker not opening in Safari (thanks @liam for reporting). If you hit this before, just refresh the page — no app update needed." — credits the reporter (social currency), states scope (Safari users), gives the action (just refresh). A bug-fix changelog is the best user ops there is: letting users see "my report got fixed" beats any points system.

Security (Security)

❌ Bad: "Security update, please upgrade." — users think: what happened? The less you say, the more they panic.

✅ Good: "Fixed a permissions vulnerability: collaborators could previously see other people's draft documents. Fixed now; all users should update to v2.4.1. No passwords or payment data were involved." — states what happened + who was affected + what to do, but never the exploit details (that's a tutorial for attackers). The last sentence — "no passwords or payment data" — is the sedative answering the exact question users fear most.

Self-check: for every entry, ask three questions — would my mom understand it? Does the user know where to click? What would they miss if they skipped this? Three passes = a qualified entry.

Public Roadmaps: Notion vs. Linear vs. GitHub Discussions

Changelogs cover the past; roadmaps cover the future. A public roadmap isn't a feature wishlist — it's commitment management: showing users where you're headed so they dare to bet their workflows on you. Three tools, three personalities; picking wrong is worse than not having one.

Notion: fastest, best for non-technical audiences

Create a public page with a board view and three columns: Planned / In Progress / Shipped. One sentence per card plus a status tag — done. Pros: zero learning curve, embeddable on your site, looks fine on mobile. Cons: weak interactivity (comments need a Notion login). Best for: productivity tools, consumer apps, products whose users don't write code. Practical tip: add "roadmaps change; the changelog is the source of truth" at the top for policy wiggle room, and archive shipped items monthly so the page doesn't become a landfill.

Linear: for teams already running on Linear

Linear's roadmap view can be shared publicly with one click, and dev progress and the public roadmap are the same data source — no double bookkeeping, its killer feature. Drag a card in Linear and the public page updates. Cons: limited free tier, engineer-flavored aesthetics. Best for: SaaS, dev tools, small teams already on Linear.

GitHub Discussions: for open-source / developer-facing products

Use Discussions voting for feature requests: one thread per idea, users vote with 👍 reactions, maintainers tag planned / in-progress / shipped. Pros: closest to the code, highest discussion quality, and a pipeline for converting contributors into code contributors. Cons: a barrier for non-technical users. Best for: open source, API products, SDKs. Practical tip: post a monthly "roadmap sync" thread mapping top-voted requests to actual scheduling — the core trust ritual of open-source projects.

Three iron rules (same whichever tool you pick)

• Only list what's actually scoped, never "just thinking": every roadmap item should be something you genuinely intend to build. Vaporware feels great until the receipts come out.
• Every item needs a status — no "planned forever": an item sitting in "planned" for 6+ months either gets built or gets honestly marked "not considering" with a reason. Users accept "no"; they don't accept radio silence.
• Roadmap and changelog link to each other: shipped roadmap items link to their release notes; the changelog notes "this one was roadmap vote #3." Once that loop closes, users start voting voluntarily — and your backlog gets a free water supply.

Code in Practice: A Reusable Changelog Timeline Component + RSS Feed Script

Theory alone won't cut it — here are two copy-pasteable code sketches. First, a React + TypeScript changelog timeline component: it fetches from your own /api/changelog, groups entries by version, and supports category badges plus "copy version link." Second, a Node script that scans markdown files in changelog/ and generates an RSS/Atom feed — so your updates can be subscribed to in RSS readers and picked up by update-aggregator services.

The changelog timeline component (React + TS)

Design principle: data structures first. Each release is an object, entries carry a category; the backend can be static JSON or a CMS. The component only renders — it never touches the data source, so switching from JSON to a database later means zero UI changes.

// types.ts — nail the data model first, shared by frontend and backend
export type ChangeKind = 'added' | 'changed' | 'deprecated' | 'removed' | 'fixed' | 'security';

export interface ChangeEntry {
  kind: ChangeKind;
  text: string;          // one plain-language sentence, written per the template
  link?: string;         // optional: link to docs or a demo
}

export interface Release {
  version: string;       // "2.4.0"
  date: string;          // "2026-10-08" (ISO)
  pinned?: boolean;      // pin major releases
  entries: ChangeEntry[];
}

// kind → badge color: one mapping used site-wide
export const KIND_META: Record<ChangeKind, { label: string; color: string }> = {
  added:      { label: 'Added', color: '#16a34a' },
  changed:    { label: 'Changed', color: '#2563eb' },
  deprecated: { label: 'Deprecated', color: '#d97706' },
  removed:    { label: 'Removed', color: '#dc2626' },
  fixed:      { label: 'Fixed', color: '#7c3aed' },
  security:   { label: 'Security', color: '#b91c1c' },
};

// ChangelogTimeline.tsx
import { useEffect, useState } from 'react';
import { Release, ChangeEntry, KIND_META } from './types';

function EntryRow({ entry }: { entry: ChangeEntry }) {
  const meta = KIND_META[entry.kind];
  return (
    <li style={{ marginBottom: 8 }}>
      <span style={{
        display: 'inline-block', fontSize: 12, color: '#fff',
        background: meta.color, borderRadius: 4, padding: '1px 8px', marginRight: 8,
      }}>{meta.label}</span>
      <span>{entry.text}</span>
      {entry.link && (<a href={entry.link} style={{ marginLeft: 8 }}>Learn more →</a>)}
    </li>
  );
}

export default function ChangelogTimeline() {
  const [releases, setReleases] = useState<Release[]>([]);
  const [error, setError] = useState(false);

  useEffect(() => {
    // Data source: /api/changelog returns Release[], newest version first.
    // Can be a static JSON file, or backed by a CMS / database.
    fetch('/api/changelog')
      .then((r) => { if (!r.ok) throw new Error('bad status'); return r.json(); })
      .then(setReleases)
      .catch(() => setError(true));
  }, []);

  if (error) return <p>Failed to load the changelog. Please try again later.</p>;
  if (!releases.length) return <p>Loading changelog…</p>;

  return (
    <div>
      {releases.map((rel) => (
        <section key={rel.version} id={`v${rel.version}`} style={{ marginBottom: 40 }}>
          <h3 style={{ display: 'flex', alignItems: 'baseline', gap: 12 }}>
            v{rel.version}
            {rel.pinned && <span style={{ fontSize: 12 }}>⭐ Major release</span>}
            <span style={{ fontSize: 13, color: '#666' }}>{rel.date}</span>
            <a href={`#v${rel.version}`} style={{ fontSize: 12 }}>Copy link</a>
          </h3>
          <ul style={{ listStyle: 'none', paddingLeft: 0 }}>
            {rel.entries.map((e, i) => <EntryRow key={i} entry={e} />)}
          </ul>
        </section>
      ))}
    </div>
  );
}

Three details decide whether this component is actually good: every version gets an anchor (so support can drop a direct link mid-argument); security entries are always red and first (the code renders in array order, so put security entries first in your data); badges don't wrap awkwardly on mobile (inline-block + margin, never float). Data source advice: start with a static public/changelog.json — one file to edit per release; switch to an API when you get a CMS. The component won't care.

RSS/Atom feed generation, the Node way

Why bother with RSS? Because your changelog deserves subscribers: users drop the feed into a reader and updates come to them; update-aggregator sites will crawl your feed too — free distribution. The logic is trivial: name files like changelog/v2.4.0.md (filename = version), put date and title in the first two lines, entries in the body.

// scripts/build-feed.mjs —— node scripts/build-feed.mjs > public/feed.xml
import { readdirSync, readFileSync } from 'node:fs';

const SITE = 'https://yourproduct.com';
const files = readdirSync('changelog').filter(f => f.endsWith('.md')).sort().reverse();

const items = files.map((f) => {
  const version = f.replace('.md', '');
  const raw = readFileSync(`changelog/${f}`, 'utf8').split('\n');
  const date = raw[0].replace('date:', '').trim();   // line 1: date: 2026-10-08
  const title = raw[1].replace('title:', '').trim(); // line 2: title: v2.4.0 dark mode lands
  const body = raw.slice(3).join('\n').trim();
  return { version, date, title, body };
});

const esc = (s) => s.replace(/&/g, '&amp;').replace(/</g, '&lt;').replace(/>/g, '&gt;');

let xml = `<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"><channel>
<title>YourProduct Changelog</title>
<link>${SITE}/changelog</link>
<description>Release notes and version updates for YourProduct</description>`;

for (const it of items) {
  xml += `
<item>
  <title>${esc(it.title)}</title>
  <link>${SITE}/changelog#v${it.version}</link>
  <pubDate>${new Date(it.date).toUTCString()}</pubDate>
  <description>${esc(it.body)}</description>
</item>`;
}
xml += '\n</channel></rss>';
console.log(xml);

Hook this script into CI: run it on every release tag, and feed.xml deploys with your static site. Then add <link rel="alternate" type="application/rss+xml" href="/feed.xml"> to the changelog page head so readers auto-discover it. Thirty lines, zero dependencies — that's the right scale for changelog infrastructure in a vibe project: sufficient, maintainable, no three new services adopted in the name of "best practice."

Release Cadence SOP: Weekly / Biweekly Checklists

Finally, the SOP. The biggest enemy of changelogs isn't bad writing — it's no rhythm: one inspired entry, then three months of silence. A fixed release cadence is compounding trust: users develop a "this team ships every Thursday" expectation, and expectation itself is retention.

Weekly releases (for fast-iterating vibe projects)

• Monday: scope the week's release. Pick "user-perceivable" changes from your agent's commits into a CHANGELOG.md draft. The filter: could my mom understand what this does for her? If not, it doesn't go in.
• Wednesday: freeze features, smoke-test the core flows (login, payment, the three core features). Vibe projects fail most often on "the agent changed A and broke B" — 10 minutes of smoke testing catches 80% of dumb incidents.
• Thursday = ship day, in this order: tag the release → run the feed script → update the changelog page → push the in-app modal (sexiest item only) → post the X update thread → reply in your Product Hunt/Show HN thread. Don't reverse the order: make the changelog reachable before you start shouting, or users land on a 404.
• Friday: read the numbers. Modal click-through, update adoption (what share of users moved to the new version), support tickets saying "X broke after the update." Breaking-change complaints get a reply within 24 hours — even "noted, we'll have a plan Monday" counts.

Biweekly releases (for products with paying users that value stability)

Same as weekly, plus three additions: send a "next up" teaser email on the first Friday (2–3 items from the roadmap, build anticipation); add a "release-notes review" before shipping — have a non-technical friend read the changelog, and rewrite anything they don't get; breaking changes require a deprecation a full version ahead — on a biweekly cadence there's no room for "announce this week, break next week," minimum 14 days' notice.

The hotfix lane

P0 production incidents skip the normal cadence: ship the patch immediately, and the Fixed entry's first sentence covers "scope + whether users must act." Template: "v2.4.2 hotfix: exports failed for some users 14:00–14:25 today, now recovered. No app update needed — just refresh the page." — a hotfix changelog must answer the three questions panicking users have: was I affected? Do I need to do anything? Is it fixed now?

Cadence advice: start biweekly, not weekly. The vibe-project temptation is "I can ship three times a day," but release cadence is for users, not for your agent. A steady biweekly beats a sporadic weekly for trust-building. Speed up once the SOP runs smoothly.

Four Real Anti-Patterns: How Changelogs Die

Four anti-patterns I've seen (and committed) — dodge them:

• The git-log dump: "fix: resolve race condition in worker pool," "chore: bump deps." That's written for machines, not humans. However tidy your agent's commit messages, they never replace one human sentence.
• Good news only: Added entries forever, never Removed or breaking changes. Users will eventually notice the missing feature — and your changelog's credibility goes bankrupt on the spot. Announce removals loudly, with alternatives attached; users trust you more, not less.
• Version numerology: bump minor when happy, patch when not, sit on 0.1.0 for three years. Version numbers are a promise gauge, not decoration. When in doubt: users must relearn something = at least minor; users' code breaks = major.
• The one-time renovation: a lovingly crafted changelog on launch day, then never touched again. A changelog is a series, not a movie poster. Accept "ugly first": three one-liners beat a blank page a hundredfold — get the rhythm running, polish the prose later.

Conclusion: A Changelog Is Product Storytelling, Not a Git Log

Back to the opening line: a changelog is not a git log for developers — it's product storytelling. Git logs answer "how did the code change"; changelogs answer "why is this product still worth using." In the vibe era, the cost of writing code trends toward zero, and what's scarce is the ability to make users perceive change — the changelog is the cheapest, highest-ROI tool for exactly that.

Starting today, do three small things: first, create a CHANGELOG.md at your repo root with the Added/Fixed six-category structure; second, get your agent prefixing commits with feat:/fix:; third, turn your sexiest update into an in-app modal on the next release. Check back in a month: if your users can name what you shipped last week, this guide did its job.

Shipped means told. Silent iteration is no iteration.