Infrastructure is easy to treat as somebody else's concern. It sits behind the interface, so it can feel separate from the product people use.
It is not separate. A slow service changes how an application feels. A failed deployment changes whether people can do their work. A system that is hard to understand makes every repair take longer.
I have spent years working on developer tools and infrastructure. One thing I keep coming back to is that the inside of a system eventually shows up on the outside. Users may never see a queue, a build pipeline, or a storage layer, but they feel the decisions made around them.
Reliability is a user experience
When a tool works consistently, people can focus on the task they came to do. When it fails in an unclear way, the tool gives them a second task: figuring out what went wrong.
That makes reliability more than an operations goal. It is part of how a product treats the people who depend on it. Clear errors, safe recovery, and predictable behavior all reduce the amount of guesswork a person has to do.
The same is true for the people maintaining the system. If only one person understands how it works, a routine change can become risky. If a failure leaves no useful clues, the repair takes longer than it should.
Make the important parts understandable
There is a temptation to solve every future problem in advance. But infrastructure that is difficult to explain can become its own source of risk. More layers do not automatically make a system more dependable.
I would rather be able to trace a request, understand a failure, and make a change without guessing. That often means choosing familiar pieces and making their responsibilities clear.
The work behind a product is still part of the product. It shapes whether people can trust the tool, and whether the people building it can keep it working.