Ship a Public Changelog and Roadmap

Public Changelog and Roadmap for Your New SaaS

Goal: Stand up a public changelog that ships weekly + a public roadmap that customers can vote on. Convert "what are you working on?" support questions into self-serve answers, reduce churn from customers who think the product is stagnant, and create a compounding SEO + AEO asset that drives inbound for years.

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Changelog v1 live in 1 day. Roadmap v1 live in week 2 of launch. Weekly publish cadence locked into the calendar from launch onward.

Why This Is Higher-Leverage Than It Looks

A public changelog is one of the most under-rated growth assets an indie SaaS has. The reasons:

It is the proof-of-life signal. Buyers evaluating you compare your changelog to your competitors'. A weekly cadence reads as "this team ships." A 6-month-old last entry reads as "abandoned project — pass." This single page can determine the close rate on a whole cohort of inbound.
It is a content engine you cannot game. Every changelog entry is a real, dated, specific thing your team did. Search engines and AI engines treat it as fresh, authoritative content. Twelve months of weekly entries become 50+ indexable pages that compound search traffic.
It pre-empts support volume. "What's new?" is one of the most common questions in support inboxes; a public changelog answers it before it gets asked.
It builds anticipation. A public roadmap turns customers into advocates — they vote, they comment, they tell their network "I voted for X on [your product]'s roadmap." Free distribution from the very people you most want as repeat buyers.

The under-investment happens because the work feels like marketing rather than product. It is both. Treat it as engineering documentation that happens to drive revenue.

This guide pairs with Onboarding Email Sequence (the launch-of-something-new email is one of the highest-engagement messages in the lifecycle), Reduce Churn (a regularly-shipping changelog reduces "product feels stagnant" churn), and AEO/LLM Citations (the changelog is high-grade input for AI engines summarizing your product).

1. Decide What Counts as a Changelog Entry

Before you ship, decide the bar. Loose bar = noise; tight bar = silence. Most teams err on one side or the other.

I'm building [your product] at [your-domain.com]. The product does [one-sentence description]. My target customer is [role / industry / company size].

Help me define the editorial bar for changelog entries. Tell me what counts and what doesn't.

For each category, decide: changelog (yes), changelog (only if grouped weekly), or skip:

1. **New customer-facing feature** — yes
2. **New customer-facing setting / preference** — yes
3. **UI redesign or significant UX change** — yes, with screenshot
4. **Performance improvement that customers will notice** — yes if measurable
5. **Bug fix that customers reported** — group weekly under "improvements"
6. **Internal refactor / migration with no user-visible change** — skip
7. **Security patch** — yes (briefly), without exploit details
8. **Pricing change** — yes, with explicit migration plan for existing customers
9. **API change / new endpoint** — yes if my product is API-first; group weekly otherwise
10. **Integration / partnership launch** — yes
11. **Rebrand or copy change** — only if it's a product positioning shift, not minor tweaks
12. **Deprecation notice** — yes, ALWAYS, with the exact removal date
13. **Beta feature opt-in available** — yes

Output as a single 2-page editorial guide I can pin to my docs. The guide should also cover:

- **Tone**: friendly, specific, brief. Talk like the founder, not like a press release.
- **Format per entry**: H2 with date + title, 1–3 sentences, optional screenshot or 30-second Loom, link to relevant docs page. Under 200 words per entry.
- **Frequency**: weekly is the floor for most products. Daily is overkill for indie scale; monthly reads as slow.
- **Categorization**: tag every entry with one of [New / Improved / Fixed / Beta / Deprecation]. Categories let visitors filter.

The single most consequential editorial decision: publish on a fixed cadence, not a "when there's enough to share" cadence. The latter has a failure mode where slow weeks become silent ones, and silent weeks accumulate into the death-by-no-changelog spiral. A weekly published with one tiny entry beats a monthly with five — readers calibrate on consistency, not magnitude.

2. Build the Changelog Page

A good changelog page renders on its own URL, gets indexed by search engines, syndicates to RSS, and drives in-app notifications. Most are missing at least one of these.

Build a public changelog page at /changelog for my Next.js App Router app.

Requirements:

1. **Storage**: changelog entries stored as MDX files in `content/changelog/`. One MDX file per entry, with frontmatter for date, title, category, tags, screenshot URL, related-doc URL.

2. **Page rendering**: /changelog as a reverse-chronological feed (newest first). Each entry rendered with: date, title, category badge, body, optional screenshot, optional Loom embed, "discuss this on [Twitter / Discord / GitHub]" link.

3. **Filters**: at the top of /changelog, four filter chips: All / New / Improved / Fixed / Beta. Selecting filters by tag.

4. **Per-entry permalinks**: every entry has a stable URL (/changelog/2026-04-29-feature-name) so I can link to a single entry from the in-app banner, support replies, social posts.

5. **RSS feed**: at /changelog/feed.xml. Subscribers like devtools / API customers will use it.

6. **Schema markup (per [AEO/LLM Citations](aeo-llm-citations-chat.md))**:
   - Article schema on each entry page (datePublished, dateModified, headline, author)
   - BreadcrumbList for navigation
   - The page-level schema improves AI engine citation rates for "what's new in [my product]" queries

7. **Subscribe affordance**: a small "Get changelog updates" button at the top that opens a modal with three options:
   - Email digest (weekly summary, integrates with my [Loops / Resend])
   - RSS feed
   - In-app only (default for logged-in users)

8. **In-app integration**: a bell icon in the app navbar that shows recent changelog entries to logged-in users. Mark-as-read state stored per user. NO red-dot badge spam — show new entries for one week, then quiet.

9. **SEO basics**: meta title "Changelog — [Product] — Updates and improvements", meta description pulling latest entry's excerpt, sitemap inclusion, internal links from /docs and /pricing footer.

Output: the Next.js page component, the MDX schema, the RSS route handler, the JSON-LD component, the in-app bell component, and 3 sample changelog entries to demonstrate the format.

The most-skipped feature: RSS. Developer audiences use it religiously, and the cost of providing it is essentially zero in a Next.js app. Skip RSS and you make your changelog invisible to one of the most-engaged segments of any developer-tools product.

3. Build the Public Roadmap

A roadmap that lives in your private Notion is just a wishlist. A public roadmap is a continuous voice-of-customer signal — which is why most teams resist publishing one (it commits them) and why doing it is a competitive advantage (it builds trust).

Build a public roadmap at /roadmap for [my product].

Three columns, named clearly:

1. **Now** — what we're actively building. 2-5 items. Each with: title, 1-paragraph description, target month (NOT date), public progress indicator (Just started / In progress / Final testing).
2. **Next** — what's queued after Now. 5-10 items. Same fields, no progress indicator.
3. **Later / Considering** — ideas we like but haven't committed to. Unlimited but reasonably curated. Voting is open here.

Every item has:
- A unique URL (/roadmap/[slug]) for permalinks
- A vote count and "vote" button (one vote per logged-in user; localStorage for anonymous)
- A comment thread (logged-in only; moderated; spam-protected)
- A status timeline showing the journey: Considering → Voted up → Now → Shipped → Linked to changelog entry

When an item ships, it moves to /changelog and the roadmap entry updates with "Shipped on [date] — see changelog entry." Don't delete shipped items; archive them on a /roadmap/shipped page so customers see momentum.

Critical principles:

- **No dates**. "Q2 2026" or "Now" or "Soon" — never specific dates. Dates create commitments you'll miss; ranges set realistic expectations.
- **No surprise additions / removals**. If "Considering" gets cut, leave it visible with a "Cut from roadmap (reason)" note. If new "Now" items appear, post a changelog entry. The roadmap is a public process, not a marketing surface.
- **Founder is the only one who moves cards**. PMs / designers can suggest moves; the founder reviews quarterly. Prevents drift.
- **Comments are public + moderated**. Customers learn from each other's threads. Spam is removed; criticism is not.

Tooling options:

- **Self-hosted** — Notion + Super.so or a Next.js implementation with Postgres. Full control, no per-user fees.
- **Canny** — purpose-built, ~$50/mo at indie scale, includes voting + comments + admin. Default for most teams.
- **Productboard / Aha!** — overkill at this stage. Reach for once you have a product team.
- **Linear public views** — if you're already on Linear, a public view of your roadmap board is the lowest-effort option.

Default if no strong reason: Canny for first 12 months. Migrate to self-hosted around customer 1,000 if SEO of the roadmap becomes valuable.

Output the public-roadmap implementation plan, the schema for items, the voting / comments wiring, and the moderation playbook.

The "no dates" rule is the difference between a roadmap that builds trust and one that destroys it. Every founder who has shipped specific dates publicly has missed them and lost credibility doing so. Date ranges set the right expectation; specific dates do not.

4. Wire the Cross-Links

Changelog and roadmap separately are useful; cross-linked they compound.

Cross-link my changelog and roadmap:

1. **From a roadmap item to the changelog**: when an item ships, the changelog entry's frontmatter includes `roadmap_item: [slug]`. Render a "shipped from roadmap" badge in the changelog entry that links back. The roadmap item also auto-updates to "Shipped on [date] — see [changelog link]."

2. **From the changelog to /docs**: every changelog entry that touches a documented feature includes a `related_doc: /docs/[slug]` link. The changelog renders a "Read the docs" CTA at the bottom.

3. **From /docs to the changelog**: for every documented feature page, add a "Recent updates" sidebar that pulls the last 3 changelog entries tagged with that feature.

4. **From in-app to the changelog**: when the user encounters a recently-changed feature, an inline "Updated [date]" badge appears next to the affected UI element, linking to the relevant changelog entry. Pulls customers into the changelog at the moment they're most curious.

5. **From transactional emails**: weekly changelog digest email subscribers get a Sunday email summarizing the week's entries. Links to permalinks. From [Loops / Resend], scheduled cron via [vercel-functions](../../../VibeReference/cloud-and-hosting/vercel-functions.md) cron job.

6. **From customer support replies**: when I answer "is X on the roadmap?" in a ticket, my saved-reply links to /roadmap/[slug] directly. Customers can vote and subscribe to updates. (See [customer-support](customer-support-chat.md).)

For each integration, output the implementation. Don't ship without item 4 — the in-app "Updated [date]" badges are what convert passive customers into active engagement with the changelog.

The in-app badges (item 4) are the most-skipped integration and the highest-leverage. Customers who never visit /changelog still see "Updated last week" right where they're using the product, click through, and become regular changelog readers.

5. Write a Changelog Entry That Actually Works

Most changelog entries fail by being too vague, too long, too marketing-shaped, or missing the "why this matters" context. A good entry is short, specific, and answers three questions in 200 words.

Help me write a changelog entry for [feature / improvement / fix I shipped this week]. Brief context:

- What changed: [describe in 2 sentences]
- Why we changed it: [the customer pain or strategic reason]
- Who it affects: [all customers / Pro tier / specific use case]

Generate the entry following this template:

---
## [Date]: [Title — verb-led, 6 words max]

[Tag: New | Improved | Fixed | Beta | Deprecation]

[1-2 sentences: what changed, in plain English. Reference the specific UI or behavior, not internal feature names.]

[1-2 sentences: why it matters for the user. Tie to the pain or workflow improvement.]

[Optional: 30-second Loom embed or annotated screenshot]

[Optional: "Read the docs" link to /docs/[slug] if applicable]
[Optional: "Discuss this" link to Twitter / Discord / GitHub]

---

Then generate three sample entries from real-feeling scenarios (a new feature, a bug fix grouped with two others, a deprecation notice). Show me the variations:

1. **New feature**: 200 words, screenshot, doc link
2. **Improvement bundle**: under 150 words, lists 3 fixed bugs without exploit details
3. **Deprecation**: 150 words, exact removal date, migration path, "questions? reach out" line

Output as Markdown ready to paste into MDX files.

A high-quality changelog entry passes one test: a customer who skim-reads it understands what changed, why it matters to them, and what to do next, in under 30 seconds. Anything that takes longer is too long.

6. Make the Cadence Sustainable

Changelogs die from the same disease as blogs: enthusiastic launches, fatigue at week 6, abandonment at month 3. Build the operating cadence that survives ordinary weeks.

Set up a sustainable changelog operating rhythm.

Weekly cadence (every Friday or chosen day):

1. **15-minute "what shipped" review**: scroll the week's commits, PRs, customer-facing changes. Pull anything that crosses the editorial bar from Section 1.
2. **Draft the entries** in MDX files, one per item or one bundled-improvements entry. 30 minutes max.
3. **Review + publish**: before the team goes home, the entries are merged. Weekly publish lands Friday evening (US time) or Monday morning (US time) — pick one based on audience.

Monthly cadence:

1. **Read the changelog from the customer's POV**: scroll /changelog as if I were a buyer evaluating the product. Does it read as "active" or "stagnant"? Adjust output if needed.
2. **Roadmap update**: review /roadmap status. Move items between Now / Next / Later / Shipped as needed. Post a "roadmap update" changelog entry summarizing the shifts.
3. **Send the monthly digest** if I'm running an email subscriber list.

Quarterly cadence:

1. **Review the editorial bar from Section 1**: did the bar produce useful entries, or noise? Tighten / loosen as needed.
2. **Audit cross-links**: are docs, in-app badges, and roadmap items still pointing correctly? Migrations break links over time.
3. **Stage one bigger entry**: a "quarter recap" post that links to the major shipped items. Drives reactivation among lapsed customers.

Failure-mode drills:

- **Slow week with nothing shippable**: publish a "this week we focused on [internal infrastructure / customer interviews / team hiring]" honest note. Honesty about non-launch weeks reads better than silence.
- **Shipped a half-broken feature**: publish the changelog entry, label as "Beta", explicitly invite feedback. Better than the alternative of customers discovering it is broken from each other.
- **Major bug shipped to production**: post-mortem-style changelog entry. What broke, what we did, what we learned. The willingness to publicize this is often the differentiator between teams customers trust and teams they tolerate.

Output: a recurring calendar template + a "what to do when the weekly cadence is at risk" decision tree.

The slow-week honesty rule is the most important. Founders who skip publishing during slow weeks teach customers that the changelog cannot be trusted to reflect the team's actual cadence. A weekly published with "small week, here's what we worked on" beats a missed week every time.

7. Convert the Changelog Into Distribution

A changelog that nobody reads is a hygiene asset. A changelog that gets shared becomes a distribution channel.

Build amplification on top of my changelog:

1. **Twitter / X thread per significant entry**: for each "New feature" entry, schedule a thread on X within 24 hours. Hook + 3-5 details + screenshot + link. Same for LinkedIn (per [Building in Public](../../../LaunchWeek/content/3-distribute/building-in-public.md)).

2. **Customer email blast for big entries**: an email to all paying customers when a major feature ships. Subject line: specific outcome ("[feature] is live"). Body: 100 words, "what's new + how to try it" + Loom. Send once per quarter at most — more than that and unsubs spike.

3. **Reddit / niche-community share**: post the major-feature changelog entry as a "Show that we shipped X" in the right niche subreddit (per [Reddit Launch Strategy](../../../LaunchWeek/content/5-launch/reddit.md)). NOT every entry — only the ones that have real news value.

4. **Press release for major launches**: roughly one launch per quarter deserves a coordinated micro-launch (Hacker News post, dedicated landing page, partner reach-outs). The changelog entry is the artifact those efforts point to.

5. **Sales-enablement**: monthly, share the month's changelog with the sales team / agency / contractors as ammo for outreach and demos. New customers should hear "we shipped X this month" within hours.

6. **AEO seeding**: every changelog entry is a candidate for AI-engine ingestion. Make sure the changelog is in `llms.txt` (per [AEO/LLM Citations](aeo-llm-citations-chat.md)) and that AI engines can index recent entries. ChatGPT and Perplexity pulling "what's new in [your product]" answers from your changelog is real distribution.

For each amplification, build the schedule + the templates. Don't let amplification become its own work — the changelog itself is the artifact; amplification is mechanical.

Output: the schedule template + the platform-specific copy templates.

The AEO seeding is the underrated long-term play. Once your changelog is well-indexed, AI engines will answer "what's new in [your product]" with accurate, dated answers — for years — without further input from you. That is a permanent distribution moat that your competitors who do not publish a changelog cannot match.

Common Failure Modes

"We started weekly, then stopped at week 6." Cadence rot. The fix is the slow-week honesty rule (Section 6). One person on the team owns the calendar slot every week, even on light weeks.

"Our changelog is too marketing-shaped." The entries read like a press release. Cut adjectives, lead with verbs, talk like a founder. "Ship faster with bulk import" is bad; "Bulk import: paste 1,000 rows at once" is good.

"The roadmap caught us — we promised X by Q2 and didn't ship." Either the roadmap item moved out (acceptable, with an explanation) or the date promise was wrong. Use date ranges, not specific months, for items still in Next or Later. Move items to Now only when work has actually started.

"Customers are upset about a deprecation we shipped." Deprecation entries need: 60+ days advance notice, a clear migration path, a contact channel for help. If any of these is missing, reschedule the deprecation.

"We have 100 changelog entries and nobody links to them." Cross-linking (Section 4) is missing. Audit /docs and in-app surfaces — every changed feature should reference its changelog entry.

"Our SEO doesn't reflect changelog activity." Schema markup is probably missing or wrong. Validate with Google's Rich Results Test. Every entry should be valid Article schema.

"The roadmap voting got brigaded by a competitor's customers." Authentication-required voting, rate limits per user, and basic spam detection on comments. Public roadmaps are a target for low-grade abuse; minimal controls prevent most of it.