What actually shipped
Echo ·
Ship enough software and you notice something strange: the release is real to everyone except the tools that produced it.
A customer feels one change. Guest checkout finally works. Support feels three fewer tickets a day, and sales finally has something to demo. But Git never saw "guest checkout." It saw a pull request in the web app, two more in the API, one in a shared payments library, and a config change in infra, landing across four repositories over eight days. The thing everyone lived as a single event was never stored as a single event anywhere.
That gap, between how software is built and how it gets understood, is what Echo exists to close.
Every reader outside engineering asks the same question: what changed, and does it affect me? Today the answer turns up a week late, if it turns up.
Humans think in features. Git stores repositories.
Version control is organized for the machine that runs the code, not for the people the code affects. Repositories, commits, and pull requests are excellent primitives for building and terrible ones for explaining.
The moment a product spans more than one repository, and almost every serious product now does, nothing in the stack answers that one question. The answer is scattered across repos, buried in PR titles written for reviewers, and correct only if you already know which changes belong together.
A raw git log won't do it either. The Keep a Changelog project has spent years pointing out that a file full of dumped commits is a transcript of the machine talking to itself.
Who this actually hurts
The gap stays invisible until you count how many people are standing on the far side of it, waiting to be told what happened.
Product wants to know what is ready to talk about. Support wants to tell a frustrated customer their bug is fixed before that customer emails again. Sales wants to demo what shipped without pinging three engineers to confirm it is live. Customers want to know whether an update touches the part of the product they depend on, and an engineer at 2am wants to know what changed under the service that just started misbehaving. Then there's the reader that isn't human: the agents and assistants now reading product documentation on someone's behalf, which need a machine-readable account of every change.
Same question from all of them. The people who most need the answer are the ones furthest from the code that holds it.
The reconstruction happens by hand, every release
Here is how the gap gets bridged on most teams: a person bridges it.
Someone opens five repositories, reads the merged pull requests, works out which ones belong to the release being announced, drops the noise, and rewrites the rest into something a human can read. Then again in a different voice for the customer changelog. Then shorter, for the internal update. Then once more for the release email.
This works right up until it doesn't. It holds while one person still carries the whole system in their head. It breaks when the team splits across services, when a feature lands as eleven PRs over two weeks, when the person who usually does the reconstruction is on holiday. The code survives all of that fine. What degrades is everyone's shared picture of what the code now does.
The hour it costs is the cheap part. The expensive part is the releases that go out silent because nobody had the hour.
Why the existing tools don't close it
There is no shortage of changelog generators. Point one at a repository and it turns commits into release notes, usually with an LLM in the middle. GitHub does it from pull request titles; semantic-release does it from commit prefixes. They're good at that, and for a single repository the problem is close to solved.
They share one blind spot: they work a repository at a time. Run four and you get four changelogs, which is fragments rather than a release. Deciding which changes across those repositories belong to the same release lands straight back on the person, and that was the expensive part to begin with.
Correlating change is the problem worth solving. Generating the text is the easy half.
What Echo is building
Echo starts a step earlier than a changelog tool. Before writing anything, it works out what actually shipped: it traces related changes across repositories through call graphs and the reference trails that tie a frontend change to the API change behind it, then groups them into one release event. The scattered work becomes one thing again, the way people already thought about it.
Then it speaks that release in the right language for each audience. A plain update for the team, a changelog for customers, upgrade notes for developers, and a machine-readable feed for the agents reading along. One correlation, many surfaces, each written to be worth someone's time.
The mission underneath is short to say and hard to do: make software changes understandable to everyone they affect.
Software will keep being built in repositories. It doesn't have to stay stuck in them.