Your team ships every week. Your customers learn about it on Discord two months late, when someone screenshots a post. Investors ask what shipped this quarter and you scroll through Slack to remember.
Every SaaS marketing site needs a changelog. Most don't have one. The ones that do usually treat it as an afterthought — a Notion page linked from the footer.
Here's why a real changelog matters, and how I built Peec.ai's in Framer.
What a real SaaS changelog does
It's not a status board. It's not a roadmap. It's a public record of what your product became this month.
Three things a real changelog gives you that Discord posts and Slack messages don't:
1. SEO surface. Every entry is a new indexed page on your marketing site. Twenty changelog entries a year = twenty new pages Google can rank. Linear, Vercel, and Resend rank for product feature queries partly because of this.
2. Sales trust. When a prospect lands on your site and sees a changelog with this week's date, they read it as "this company ships." When the changelog hasn't been updated since Q3, they read it as "this company is dying."
3. Investor and acquirer clarity. Anyone doing due diligence will look at your changelog. A consistent public log of shipped work is a credibility signal that no founder pitch deck can match.
The fact that most SaaS marketing sites don't have one is exactly why building one is leverage.
What I built for Peec.ai
Peec.ai is an AI search analytics platform. Their team ships features weekly and the changelog gets a new entry to match.
Before the changelog existed, product updates went into Discord, occasionally into a customer email, sometimes into a tweet. Most of them disappeared.
The build itself is simple:
One CMS collection called Changelog, with five fields: title, summary, category, date, body content.
One template page that renders any entry, with an accordion for improvements and fixes (more on that below).
One index page that lists all entries, newest first, with category filters.
That's it. Thirty minutes of CMS setup, a couple of hours on layout and template design, and a small piece of custom code for the accordion logic.
The hard part wasn't the build. The hard part was making it boring enough that the team would actually keep using it.
The CMS rules that keep it alive
Most changelogs die because the system is too complex for the marketing or product team to maintain without the freelancer or developer who built it.
Four principles I apply to every CMS-driven section on a client site:
1. Limit field types to what a non-technical team won't get confused by.
Rich text, plain text, image, date, dropdown. That's it. No reference fields linking to other collections. No nested structures. The moment your CMS requires a tutorial, your team avoids it.
2. Pre-fill everything you can.
The category dropdown in Peec.ai's changelog has exactly three options. New feature. Improvement. Bug fix. Not "select category." Not "add a new category here." Three options, forever. Removes a decision.
3. The preview should match the published page.
In Framer's CMS, you can preview an entry before publishing. If the preview is ugly or confusing, the team will second-guess every post. Spend time making the preview accurate. It's the difference between "I'll write this up later" and "I'll add it in two minutes."
4. Hide sections automatically when they're empty.
This is the one most builds miss. A changelog entry might be "just a new feature" with no improvements or fixes. Or "just a bug fix" with no new feature. The team shouldn't have to think about which sections to delete or how to lay things out — the system should handle that.
The empty-state problem and the custom code that fixes it
The Improvements and Fixes sections on each Peec.ai changelog entry are accordions. The team writes the content in two CMS rich-text fields, and the accordion expands or collapses on the live page.
Here's the problem: Framer's native CMS visibility conditions work fine when the conditional element is a standard layout block. You connect the CMS field, set "hide if empty," done.
They don't work cleanly inside a custom component like an accordion. The accordion has its own internal logic — header, expand button, content area — and Framer's native conditions can't reach inside it to hide the whole component based on whether the source CMS field has content.
So I built a small custom code wrapper around the accordion. The component reads the CMS field. If the field is empty, the whole accordion doesn't render — no empty "Improvements" header, no collapsed accordion with nothing inside, no awkward gap in the layout. If the field has content, the accordion renders normally.
For the team writing entries, this means zero extra steps. They fill in whichever fields are relevant for that entry. They leave the rest blank. The page lays out correctly either way.
It's the kind of small invisible decision that separates a CMS the team actually uses from one they avoid.
Why Framer specifically
You can build a changelog in Notion, in Linear, on a separate subdomain — plenty of SaaS companies do.
Framer's advantage here is that the changelog lives on your marketing site. Same domain. Same design system. Same SEO. A visitor who lands on your homepage can click into the changelog and stay in the same brand experience. A Google searcher who lands on a changelog entry can navigate to your pricing page in one click.
A separate changelog subdomain breaks all of this. The SEO doesn't compound, the brand experience splits, and the analytics live in two places.
Build the changelog where the rest of your marketing site lives. Framer's CMS is built for exactly this — with custom code for the edges Framer's native tooling doesn't quite reach.
The handoff
Building the system is half the work. The other half is making sure the team actually uses it after launch.
What most freelancers do: send a Loom walkthrough and disappear.
What works better: a 30-minute call with the person who'll publish entries — usually a marketer or PM, not the founder — where they publish their first entry while you watch. They find the buttons. They hit publish. You answer two questions. Done.
The Loom is the backup. People learn by doing.
The changelog I built for Peec.ai gets a new entry every week. I haven't touched it in months. That's the goal.
If you're a founder reading this
Two questions worth asking your team this week:
Where does someone outside the company go to see what we shipped last month?
If the answer involves Discord, Slack, Twitter, or "I'll send you a link" — you don't have a changelog. You have scattered updates.
Building a real one in Framer takes a few days. The compound value over a year is significant: more indexed pages, better sales conversations, clearer investor narratives.
What I'd add next
If I were building Peec.ai's changelog from scratch today, I'd use Framer's updated CMS for one more thing: bulk import for past entries. The 2026 CMS update added CSV import that handles dates, references, and rich text. For SaaS companies migrating from Notion changelogs or Google Docs, that's an hour saved per migration.
I'd also use the new bulk-action capabilities to retroactively re-categorize entries when the team's category taxonomy changes — which it always does after the first 20 posts.