What is observability when you do not have a platform team?
Observability sounds like an enterprise hobby. Flame graphs. Cardinality budgets. A dedicated squad that tends Grafana like a bonsai tree while the rest of the company ships features.
Most product companies will never have that squad. They still need to answer a basic question when something feels wrong: what broke, for whom, and since when?
For a small team, observability is not a product category you buy off a Gartner quadrant. It is the minimum instrumentation that lets a human debug reality without guessing, without SSH folklore, and without waiting for a customer to post a screenshot on Twitter.
My take is blunt: if you cannot answer three questions in under ten minutes, you do not have an observability problem. You have a visibility problem. More dashboards will not fix it until the signals exist.
What the word is supposed to mean (and what it means for you)
In the big company sense, observability means you can infer internal state from outside outputs: logs, metrics, traces. That is the textbook version. Fine. Useful at scale.
In the small company sense, it means you can detect pain early and find the cause without turning every incident into a séance. If your stack cannot tell you "checkout failed for twelve users after the 2 p.m. deploy," you are flying blind. Angry customers are not a monitoring strategy.
The three questions that actually matter
Forget the vendor matrix for a minute. Can you answer:
- Is it broken right now? A health signal. Binary is fine at first.
- How bad is it? A count, a rate, or revenue impact. Not vibes.
- Where should a person look first? Request id, error class, recent change.
If you can answer those in under ten minutes, you are ahead of most early teams. If you cannot, buying Datadog Pro will not help until someone instruments the paths that matter.
That is the whole bar. Everything else is optimization you earn later.
A starter kit that fits in one sprint
Logs with structure. JSON beats prose in a crisis. Include request id, user id when safe, route, and error code. One searchable place beats five random files on five random servers.
One golden metric per critical flow. Signups completed. Orders paid. Jobs finished. Not fifty vanity charts that nobody opens until the board deck is due.
Deploy markers. When you ship, mark the timeline. Most "mysterious" regressions are timed to a release someone forgot. The deploy marker is free. The week of guessing is not.
Alert on customer pain, not CPU poetry. Page a human when payments fail or the queue stalls. Do not page on every blip that self clears. Your on call engineer is a person, not a circuit breaker for Grafana anxiety.
A boring weekly review. Fifteen minutes. What fired? What was noise? What still has no owner? That ritual beats a perfect SLO program you never maintain.
What to skip early (and what you cannot skip)
You can defer distributed tracing across twelve services if you have two. You can defer a perfect SLO program until you have a stable definition of "good." You can defer the fancy vendor bake off until you know what you would alert on.
You should not defer basic error visibility. You should not defer backup restore tests. Those are survival, not polish.
Teams that skip survival to buy tooling are performing adulthood for investors. The demo looks serious. The 3 a.m. page still goes to nobody.
Tools are secondary. Trust is not.
Datadog, Grafana Cloud, Axiom, OpenTelemetry, plain CloudWatch: pick something your team will actually open when something hurts. The failure mode is never the wrong vendor logo. It is instrumentation theater that nobody trusts because half the alerts lie.
Same rule as total cost of "we will just use X": seats and agents are cheap compared with a week of silent data loss or a payment path that fails without anyone knowing.
Tie it to how you ship
Observability is part of shipping, not a polish phase you schedule after "real features." If a feature cannot emit a signal when it fails, it is not done. That habit is closer to product engineering versus "just development" than to buying an APM logo for the slide deck.
A founder once told me observability was "for later." Later arrived as a weekend outage during their biggest promo. The fix took forty minutes. The customer trust took months.
A practical bar for founders and PMs
Ask your builders these three questions. Do not accept hand waving.
- What alert would wake you for our top revenue path?
- Where do you look first after a bad deploy?
- When did we last restore from backup on purpose?
Vague answers mean the platform team you do not have is currently you, without the tools or the habits.
What I would do again
Start with one golden metric on the money path. Structure logs before you debate tracing vendors. Alert on user pain, tune noise weekly, and treat "can we see it break?" as part of definition of done.
Here is what I would not do again: buy observability tooling before defining what should wake a human. That is how you get a expensive dashboard full of charts that prove the CPU is fine while checkout is on fire.
Work with Kleto
I am James Cowan, a product engineer and the founder of Kleto. Kleto is a product engineering agency that ships production software from strategy through handoff. We help small teams put simple signals on the paths that matter before scale theater arrives. If that matches your stack, contact Kleto and we will scope a sensible first step.