Instrumentation first

The first thing we build is not the feature. It is the ability to see the feature: metrics, traces, structured logs, and a dashboard that shows the golden signals for whatever we are about to ship.

This is not ceremony. It is what makes every subsequent decision cheap.

What instrumentation-first buys you

• Deploy with a hypothesis. You know what "working" looks like in numbers before the code runs, so the deploy is a measurement rather than a hope.
• Debugging by query, not by archaeology. When a request misbehaves, the trace tells you which service, which query, which retry — in one lookup instead of an afternoon of log-grepping.
• Capacity conversations with evidence. "Do we need to scale it?" has an answer in the graph rather than an opinion in the meeting.

What we actually wire up

• RED metrics — rate, errors, duration — for every entry point.
• Traces across service boundaries, with the correlation id carried through queues, not just HTTP.
• Structured logs with the fields you will actually filter on: entity id, tenant, outcome.
• Business counters for the things your product measures: orders completed, forms submitted, jobs queued.

The order of work

1. Skeleton with telemetry end to end — one request traced through the whole path, one dashboard showing it.
2. The feature, behind the telemetry you just proved works.
3. Alerting on the signals once you have watched them for a week and know what normal looks like.

Step 3 last is deliberate: alerts tuned before you know the baseline are just noise with a pager attached.

What it costs

A day or two at the start. What it saves is the first real incident in production, which is where an un-instrumented system spends its first week — and where trust in a new system is usually lost.