· 6 min read
Why a changelog is the cheapest trust you can buy
Before anyone buys your SaaS they run a check you never see — is this thing still alive, or abandoned under the bed? Your changelog answers it in about four seconds, one way or the other.
Somewhere between reading your pricing page and entering a card, every serious buyer runs a check you never see and cannot influence after the fact.
They are not checking whether your features are good. They decided that on the landing page. They are checking something quieter and much more decisive: is anyone still working on this?
Because the risk they are weighing is not that your product is bad. It is that it is abandoned — that they will migrate their team onto it, build a workflow around it, and discover in eight months that the founder moved on, support emails go nowhere, and the roadmap has been a screenshot since last spring. Everyone who buys software has been burned by this once. They check now.
What the check actually looks like
It takes about a minute, and it is remarkably consistent. They look for a timestamp — any timestamp — attached to human activity:
- When was the last blog post?
- When did the founder last post publicly?
- Does the documentation mention a version that shipped this year?
- Is there a status page, and does it show recent checks?
- When was the last changelog entry?
That last one carries more weight than the others, and it is worth understanding why. A blog post is marketing, and marketing can be outsourced. A social account can be scheduled. Documentation can sit unchanged for a year and still look current.
A changelog is different. It is dated, specific, and cumulative. "Fixed CSV imports timing out on files over 50MB — 3 August" is not a thing you can write without having done the work. It is the only page on your site that is difficult to fake, which is exactly why it is the one that gets trusted.
The four things a buyer reads out of it
They are not reading your entries the way your users do. They are extracting four signals, usually without articulating any of them:
Someone is still here. The single most important bit of information on the page, and it is carried entirely by the date at the top.
The pace is sustainable. Not "did they ship a lot", but "did they ship consistently". Eleven entries in one week and nothing for five months reads worse than one entry a fortnight, every fortnight. One pattern says a product; the other says a burst of enthusiasm.
Bugs get fixed. This is the one most founders get backwards — more on it below.
They talk to their users. Entries that reference requests, or link back to the person who asked, say something no marketing page can: that feedback here goes somewhere. If you run a public feedback board, that connection becomes visible rather than claimed.
The stale changelog problem
Here is the uncomfortable part, and it is the reason this article exists.
A changelog whose newest entry is from March does not read as neutral. It reads as evidence. You have built a page whose entire job is to display a date, put it in your footer, and pointed every evaluating buyer at proof that nothing has shipped in five months.
No changelog at all is ambiguous — maybe they publish elsewhere, maybe they are heads-down. A stale one removes the ambiguity and answers the question the wrong way, in public, permanently, to everyone who checks.
This is not an argument for taking it down. It is an argument for the thing that makes it survive: entries have to be small enough, and close enough to the work, that publishing one is not a project. We took that apart properly in Build a changelog effortlessly — the short version is that an entry which starts half-written, at the moment the work lands, is the only kind that still exists in month six.
Cadence beats completeness. Nobody is counting your entries, and a gap of three weeks where nothing crossed the bar costs you nothing. A gap of five months is a different signal entirely — and the distance between those two is roughly one entry a fortnight.
Why "Fixed" builds more trust than "New"
The instinct is to publish only the good news: new features, big launches, things that make the product look like it is growing. Bug fixes feel like admitting the product was broken.
It reads as the opposite. A changelog containing nothing but new features describes a company that ships and never looks back — which every buyer who has filed a support ticket knows is not how software works. It looks curated, because it is.
A changelog with a steady thread of Fixed entries says something far more
useful to someone deciding whether to trust you: when I find a bug, it will
get fixed, and I will be told. That is the actual question behind "is this
supported", and no amount of feature announcement answers it.
The same logic runs through everything on this list. Publishing your uptime honestly — including the incidents — builds more confidence than a page claiming 100%, because one is checkable and the other is a claim. If you are monitoring your endpoints anyway, the incident history is trust you have already earned and are not yet showing.
Put it where the check happens
None of this matters if the buyer cannot find the page during the minute they spend looking.
- In your footer, on every page. This is where people look first, and it costs you one line.
- On your pricing page. It is the highest-intent page you have, and the moment the abandonment question is loudest. A quiet "last updated 3 days ago" link does more work there than another testimonial.
- In your product, for the customers you already have. Renewal is the same trust question asked later, by someone with more evidence. A floating "What's new" badge with an unread dot puts each release in front of them without an email.
- In your RSS feed, for the handful who care most — and for every AI assistant now summarising vendors on a buyer's behalf.
- In sales and procurement replies. "Here is our changelog" answers the vendor-risk section of a security review faster than a paragraph about your commitment to the product.
The compounding version
Individually, each of these is a small signal. Together they answer the whole question.
A changelog shows the product is moving. A feedback board shows requests go somewhere and get answered in public. A status page shows you are honest when things break. Put all three on one hub — here is a live one — and a buyer's minute of checking returns the same answer three times from three independent directions.
That is a stronger position than any trust badge, and it is a byproduct of work you were already doing. The loop that connects them is the interesting part: a request comes in, you ship it, the entry announces it, and the person who asked finds out — which produces both the trust signal and the next request.
Most SaaS products never get there, not because it is hard, but because publishing the entry was a separate chore that quietly stopped. Which is why the newest date on your changelog is, for the person deciding whether to trust you, the most load-bearing number on your website.