Shipping a change without a bad evening
The question before any release is not whether it works. It is what you will do in the twenty minutes after it does not.
Most releases are fine. The ones that are not tend to fail for reasons nobody could have predicted, which is exactly why the preparation is about recovery rather than prediction.
Write the way back first
Before you release, answer one question in writing: how do we undo this, and how long does it take? If the answer is longer than ten minutes, or if it is "we would have to think about it", you are not ready — not because the change is bad, but because you will have to think about it while something is broken and people are asking.
Some changes genuinely cannot be undone: a data migration, an email that went out. Those need a different kind of care — a smaller first batch, a test on your own account — precisely because the escape route does not exist.
Release when the people who can fix it are awake
Friday afternoon is the worst slot and remains popular because it feels like clearing the desk before the weekend. What it actually does is put the discovery of any problem into Saturday, when the person who knows the change is unreachable and the person who is reachable does not know it.
Tuesday and Wednesday mornings are the good slots. You get a full working day of real usage while everyone who touched it is at a desk. A release that waits four days is almost never worse than a release nobody can support.
Watch the thing you changed, not the dashboard
After a release, people glance at a general health view, see green, and move on. General views are slow to notice a specific break — a form that fails for one browser, a step that silently skips.
Spend the first fifteen minutes using the actual thing you changed the way a customer would. It sounds too simple to matter and it catches more than monitoring does, because monitoring only reports the failures somebody thought to instrument.
Tell support before you tell the world
The people who answer messages should hear about a change before a customer describes it to them. Otherwise their first contact with your work is someone confused, and they have to guess whether it is a bug or intended.
Two sentences are enough: what changed, and what someone might notice. Send it the same morning. This is the cheapest possible action and it is the one most often skipped, because the person releasing is thinking about the code and not about the person who will be asked about it at four o'clock.
Questions people actually ask
What should I prepare before a release?
The way back. Write down how to undo the change and how long it takes; if that is longer than ten minutes or needs thinking about, you are not ready — you will be thinking about it while something is broken.
When is the best time to release?
Tuesday or Wednesday morning, so you get a full working day of real usage while everyone who touched the change is at a desk. Friday afternoon pushes the discovery of any problem into Saturday.
How should a change be announced?
Tell whoever answers customer messages before customers do — two sentences: what changed and what someone might notice. Otherwise their first contact with your work is a confused person and a guess.
