Observability First
A system that cannot explain itself is hard to operate, no matter how clean the code looks.
Observability starts with questions. What would we want to know if this request were slow? Which fields would help us tell one kind of failure from another? Those questions belong in the design conversation, alongside the API shape and the data model. Adding logs later usually produces noise instead of answers.
The strongest signal is often a small, consistent set of structured events. A request identifier, a few domain-specific fields, and a clear notion of success or failure can carry more weight than a verbose log line. Metrics and traces fill in the shape over time. Together they turn production from a black box into something a team can reason about.