Summarize with AI
Good changelog page design examples share one shape. Each entry has a plain headline that names the change, a date, one image or short clip of it working, and two or three sentences on what a user can now do. Small fixes go in a short list underneath, never in the headline.
For an AI company this page matters more than it looks. The doubt every AI startup meets is that it is a thin layer over someone else's model. The changelog is the one page where months of eval and orchestration work can show up as dated, specific facts. Most teams treat it as a dump of release notes instead, and the depth stays invisible.
Twenty-six Tuesdays of Improvements and bug fixes
Picture an AI meeting notes tool. Its changelog sits at /changelog, linked in the footer between Careers and Status. Every Tuesday for six months there is a new entry. Every entry has the same title, Improvements and bug fixes, the same grey version tag, and three bullets. Fixed an issue with calendar sync. Improved summary quality. Performance improvements.
Behind those bullets sits a different company. In week four the team built an eval suite from a few hundred real transcripts and stopped shipping any prompt change that failed it. In week eleven they moved summaries to a newer model and rewrote the system prompt around it. In week nineteen they started streaming the summary, and the wait before the first line appears dropped by about 40 percent.
A visitor learns none of that. Improved summary quality is the line that covers the eval suite. Performance improvements is the line that covers the latency work. The two hardest things the team did all year are filed under the two vaguest phrases on the page.
The founder who gives the talk on calls instead
The founder knows every one of those stories. He tells them on investor calls, usually in the last ten minutes, after someone asks what happens when the model providers ship this themselves. He shares his screen and scrolls through a doc of eval scores that nobody outside the company has seen.
A candidate for a senior engineering role asks what the hard problems are, and he gives the same talk again. Nobody on the team has opened the changelog in months, because a release script writes it from merged pull requests. When it comes up, the line is that the changelog is for existing users and they only care that bugs get fixed.
So it gets less care than any other page on the site. Yet it is one of the few pages that a skeptical engineer, an analyst at a fund or a reporter will open on purpose, because they want to know one thing: does this team actually ship hard things?
Why a changelog is the cheapest proof you are not a wrapper
Most advice treats the changelog as a retention tool. For an AI company that is the wrong reader. The reader who matters most has not signed up yet, and is trying to decide whether there is anything under the chat box.
Here is the case. A homepage can say built on proprietary evals, and anyone can type that sentence. A changelog entry dated in March that says every summary change now runs against four hundred real transcripts before it ships is harder to fake. Twelve months of entries like it are close to impossible to fake. It is the only page on your site where claims come with dates.
That matters because of how you are priced. Investors now ask a blunt question at Series A: would this company still have a reason to exist if a foundation model provider shipped something ten times better tomorrow? A strong benchmark no longer counts as an answer. The Series A bar for AI startups is around 3.5 million in ARR, up from roughly one million three years earlier (Carta, Q1 2026), and seed-stage AI startups raise at valuations roughly 42 percent above non-AI peers. A company read as a thin layer gets underwritten as one, however deep the work goes.
Looking like every other AI startup is a site-wide problem, and we wrote about why AI startups end up looking generic before. The changelog is narrower. It is one page, a few hours a month, and it answers the one question your homepage cannot answer without sounding defensive.
One entry, before and after
Before: Improvements and bug fixes. A grey v2.14 tag. Improved summary quality. Fixed calendar sync for some users. Performance improvements.
After: a headline that reads Summaries now pass a four hundred transcript check before every release. Under it, the date and a short clip of the same meeting summarized twice, the old version giving one action item to the wrong person and the new one getting all three right. Then two sentences: what the check is, and what it caught in its first month. Last, a short list headed Fixes, where calendar sync goes.
The Linear changelog is the cleanest version of this shape. Each entry has a date, a named headline such as Priority inbox, an image or video, a few paragraphs, and then separate lists labeled Fixes and Improvements. The small things are recorded, and they never take the headline. The Cursor changelog works the same way for a dev tool, with headlines like Cursor Projects and an opening paragraph that says what changed before any detail.
The rule underneath both is simple. The headline names what a user can now do or will now notice. It never names the internal project, and it never says improvements.
Model changes users will notice get their own entry
This is the part a SaaS changelog has no slot for. When you move to a new model, the output changes. Summaries get longer or shorter. Tone shifts. Formatting moves around. Something that used to work now gets refused. Users notice within a day, and if the changelog says nothing, they assume the product got worse or broke.
A model entry should say four things. Which behaviour changed, in plain words. What you tested before switching. What got better. And what got slightly worse, if anything did, with how to report it. You do not have to name the provider. Name the behaviour.
That fourth line is the one most teams cut, and it is the strongest line on the page. Only a team with real evals knows what got worse. Saying so in public is the clearest sign there is a test suite behind the product and not a single prompt. Latency belongs here too. Time to first token is a product number, so when it drops, write it up like a feature.
Show the change first, then link to where it lives
An entry that ends in text is a dead end. Lead with the thing working, then explain it, then link to the screen, the docs page or a live demo. On the Chariot site we designed and built for a speech AI lab, every section shows what the model does before the text explains it, and the demo on the site is the way in. A changelog entry can follow the same order: clip first, sentence second, link third.
Placement matters as much as the entries. A changelog linked only from the footer is a page you are hiding. Put it in the main nav, and add one line under the hero that names the latest real change and its date. The companies founders point to when they ask for the Linear, Vercel and Raycast look give their release notes the same type and care as the homepage, and that is part of why they read as serious.
A cadence and naming system to set up this week
None of this needs a redesign to start. It needs a person and an afternoon.
- Rewrite every generic headline from the last three months. If an entry was only fixes, merge it into the next real one.
- Pick a cadence you can hold, such as every second Thursday. A steady, smaller rhythm beats weekly entries that say nothing.
- Give the headline to a person. The release script can draft the Fixes list. A human writes the headline and the two sentences.
- Use three labels: Model, Product and Fixes. Every Model entry says what you tested and what changed in the output.
- Put one screenshot or short clip on every headline entry. If you cannot show it, ask whether a user will notice it.
- Write up the three biggest invisible projects from the last six months, like the eval suite or the model move, as dated entries marked as written later.
- Move the link out of the footer and into the nav, with a one-line latest note under the hero.
If you would rather hand the page to a studio, start with a shortlist built for this kind of product, such as these Framer design agencies for AI devtools, and ask each one to show you a changelog they have designed.
Studio Maydit designs and builds websites for AI founders in the US, UK and Europe, in Framer, Webflow and custom code. A fixed-scope project runs three to four weeks. On an AI company's site, the changelog, the docs entry points and the product page are where depth either shows or disappears, so we treat them as main pages, not leftovers. If your team built far more than your site admits, book a 30-minute call and we will read your changelog with you.
