What you get
You get a word “done” you can trust.
Most leaders have heard “it’s deployed” about a release that was, in fact, not working. The change went out, the message said so, and the product behind it was broken in a way nobody had looked at yet. The report and the product had quietly parted ways. The first person to find out was often a user.
This ability closes that gap. A release is not done when it has been sent out. It is done when the product your users reach is running and answering, on the version that was meant to be there.
Answering, not just sent. Your product answers its health checks before the release is marked done. A release that went out to a product that does not answer is not counted.
The version that was shipped. The running product must be on the version that was released. A product that answers but still runs an earlier version has not received the release, so the release is not counted either.
Done, or sent back. There is no third state that reads as finished but is not. A release either meets both conditions and is marked done, or it goes back. What your users get when a release goes back, and the fix that follows it, are covered on their own pages.
Where this holds, and where it does not
This is true only where your product reports its health. A product that answers health checks can be held to this. A product that reports nothing cannot, and for that product we will not say a release was proven to be running. If you want this for a product that does not report its health yet, that is a conversation worth having first.
It is also not a promise that nothing will ever go wrong in production. It is a narrower and more useful promise: a release is not called done until it is running and answering on the shipped version.
What it looks like in practice
Picture the releases for your product as a short list.
The newest one at the top reads done. That word carries meaning: the running product answered its health checks and was on that version. Below it, an earlier release reads sent back. That one never counted as done, and nobody had to tell you otherwise later.
For an engineering leader, this is one less status to double-check by hand. For a product leader, it means the release you announce to customers is the one they are actually using. For a founder, it is the difference between hearing “it’s out” and knowing it is running.
You decide what ships. Nothing reaches your users without your approval. Once a release you approved goes out, its done means done.
Where to start
Tell us which of your products reports its health, and we can talk about holding its releases to this in a first conversation.
