Durability is designed on the calm days.

Before launch, three questions:
What happens when this part fails?
Who can repair it without its author?
What can we remove and lose nothing?

Systems built on those answers turn every incident into an upgrade.

Build for the worst day, and every other day gets easier.

Going deeper

Systems earn trust in the moments when something breaks. The work that decides those moments happens much earlier, in design reviews and launch checklists, while there is still time to think.

Why the three questions work

“What happens when this part fails?” turns hidden assumptions into designed behaviour: a timeout, a fallback, a clear error. “Who can repair it without its author?” spreads knowledge before it is urgently needed. “What can we remove and lose nothing?” shrinks the surface where failures can start.

These questions cost little on a calm day and save a great deal on a hard one. Answering them in a design review takes minutes. Discovering the answers during an incident takes far longer, and the team learns far less.

A practical method

Add the three questions to every design review and launch checklist, with written answers.
Name the failure behaviour of each critical component: what the user sees, what the team sees, and what happens to the data.
Make repair a team skill: a short runbook, a second person who has fixed it in practice, and dashboards anyone can read.
Remove before you add: retire unused features, flags and dependencies as part of every major release.
Close every incident with one design change, so each failure leaves the system stronger.

What it looks like in strong teams

Incidents are calm, short and well documented. New engineers fix production issues in their first months. The codebase gets simpler over time. Launch days feel routine because the hard thinking happened earlier.

Design for the worst day while the days are calm, and reliability becomes part of the culture.