Every engineering decision has a cost

The comfortable half of the sentence

Teams love the first half of a decision:

• “We’ll cache it — it’ll be faster.”
• “We’ll split it into services — teams can move independently.”
• “We’ll abstract this — we’ll stay flexible.”

Those sentences can be true. They are incomplete.

The bill arrives later

| Decision | What you buy | What you often owe | |----------|--------------|--------------------| | Cache | Latency | Invalidation, stale reads, debugging “why is it wrong for 5 minutes?” | | Extra service | Team boundaries | Network failure modes, versioning, local-dev pain | | Deep abstraction | Reuse | Indirection, harder onboarding, fear of touching the core | | More config | Flexibility | Combinatorial testing, “it works in prod config only” |

None of these are forbidden. Unpriced decisions are.

A simple test before you say yes

Ask four questions:

1. What problem are we solving this week?
2. What new failure modes appear?
3. Who pays when this is wrong — and how will they notice?
4. What would we delete if this bet fails?

If you cannot answer (4), you are not making a reversible decision. You are making a hope.

“Boring” is often the unpaid invoice you skip

Senior engineers are not allergic to new ideas. They are allergic to unpaid complexity.

Sometimes the right call is a monolith a little longer, a synchronous call a little longer, a duplicated query a little longer — because the organization cannot yet operate the elegant alternative.

Elegance that the team cannot run is not elegance. It is deferred outage.

How we want to write about systems

When we publish teardowns, we will try to show both columns: what we chose, and what it cost — in time, risk, and attention.

If a post only celebrates the win, treat it as marketing. Engineering writing should leave you able to disagree with the decision and still learn from it.