Well-funded engineering teams rarely ask whether they need all of this. Constrained ones don’t have a choice.
Teams with budget add tools. Prometheus, then Grafana, then a distributed tracing solution, then a log aggregation platform, then an APM on top of all of it. Each addition feels justified. Each one solves a real problem. And slowly, the observability stack becomes its own system to maintain — with its own costs, its own failure modes, and its own team of people who understand it.
The constrained team can’t do that.
When you can only afford one tool, you have to decide what that tool needs to tell you — and that constraint turns out to be an advantage. When you can’t retain logs forever, you have to decide what’s worth keeping. When you can’t instrument everything, you have to decide what actually matters. Those decisions — forced by budget — are exactly the decisions that well-funded teams postpone indefinitely.
The result is that constrained teams often end up with clearer observability architecture than rich ones. Not because they’re more disciplined, but because the constraint made the decision for them.
This is what the poor man’s stack actually teaches: observability is not a product you buy. It’s a set of decisions you make. What does healthy look like? What signals change behavior? Who owns the response when something breaks? A cheap stack can’t hide the absence of answers to those questions. An expensive one can — for a while.
The teams that struggle most with observability aren’t the ones with too few tools. They’re the ones with too many signals and no agreement on what any of them mean. Dashboards nobody reads. Alerts nobody trusts. Traces nobody queries because nobody remembers why they were added.
More budget just means the problem scales quietly alongside the tooling.
A minimum viable observability stack — metrics for early warning, logs as evidence, traces only when the first two aren’t enough — forces a hierarchy. It forces you to think in layers: what tells me something is wrong, what tells me where, what tells me why. That hierarchy is architectural. It reflects decisions about your system that no tool can make for you.
The uncomfortable truth is that most teams don’t need more observability. They need clearer ownership of the observability they already have. The poor man’s stack just makes that undeniable — start by auditing what you have, and asking who actually acts on it.
Written by Miguel Hernández