The first time a client of mine refreshed a page and expected it to be there, and it was, I understood something I had been missing for years. Reliability is not a technical achievement. It is a form of respect. You are telling the person on the other end that their time is not a thing you are willing to waste.
An unreliable system insults the user twice — once by failing, and once by forcing them to treat every subsequent success as provisional. They stop planning around it. They keep their own notes. They build a private protocol for surviving your product. That tax is real, and they will eventually pay it to someone else.
Launch day is the easy day
Industry culture rewards the launch. Nobody writes the thread about the four hundredth consecutive day your service met its SLO. That day is harder than the launch, and it matters more. Launch day had the team awake and watching. Day four hundred had no one watching, and it still behaved.
"Operations is where strategy goes to keep its promises."
— FIELD NOTE
The features that demo well are designed on whiteboards. The features that are loved are forged in on-call rotations, runbook rewrites, and the unglamorous rebuilds of the part that always wakes somebody up at 3am. Reliability is the story of the people who chose the unglamorous part.
A contract, not a feature
I treat reliability as a contract with the user, not a line item in the backlog. A new feature might buy you a week of attention. A reliable product buys you a decade of trust. I would rather take the decade, every time, and build the features inside it.
That is why stability gets priority before polish on my desk. The polish arrives later, and it arrives on top of a surface that did not move. That is the only surface polish is worth putting on.