Build vs. buy (or embed) for shared services

Expected question

"You've identified a capability two or more teams need — say, cost tracking, or notification delivery. Do you build it as a shared service, embed the logic in each consumer, or buy a vendor solution? Walk me through how you decide."

Variant forms

Interviewers often ask the same trade-off with different framing — recognize the archetype:

"Build vs buy vs embed — how do you decide for a shared FinOps or auth capability?"
"When does a shared internal platform beat three copy-paste libraries?"
"Tell me when buying a vendor is the Staff+ answer, not a cop-out."
"How do you avoid building a platform nobody adopts?"
"Walk me through ownership: who on-calls a shared service when consumers outnumber builders?"
"Our team wants to own notifications end-to-end — when do you push for a shared bus?"
"How do you reverse a bad 'shared service' that became a bottleneck?"
"Compare 'thin shared library' vs 'thick shared service' for policy enforcement."

The question, as it might actually be asked

"You've identified a capability two or more teams/services need — say, cost tracking, or notification delivery. Do you build it as a shared service, embed the logic in each consumer, or buy a vendor solution? Walk me through how you'd decide."

The framework

Three real options, each with a real cost:

Embed the logic in each consumer. Fastest to ship for the first consumer. Gets progressively worse with each additional consumer — N copies of the same logic drift apart, and there's no way to answer a cross-consumer question (a total, a comparison) without reconciling N independently-evolving implementations after the fact.
Build a shared, standalone service. Higher upfront cost (a new deployable, a new interface contract, consumers must integrate over a network call instead of a function call). Pays off specifically when a cross-consumer question is a real requirement, not just a nice- to-have — because only a shared source of truth can answer it correctly.
Buy a vendor solution. Right when the capability is genuinely commodity and undifferentiated — the org gains nothing from owning the implementation. Wrong when the capability needs deep integration with your own domain model (which "generic" vendor tools rarely fit cleanly), or when the vendor relationship itself becomes the new coupling problem (see behavioral/04's EDI story — a licensed vendor integration that became the thing worth migrating away from).

The worked example, not hypothetical

agent-finops is the real decision, not a thought experiment. Two platforms (AegisAI, AegisLoop) both needed real cost metering. The first draft of the fix chose option 1 — embed corrected logic in each repo separately. Midway through planning, the requirement that actually mattered surfaced: a real cross-tenant budget total is impossible with option 1. Two repos independently computing "their own" cost can never answer "what is our total AI spend right now" without a shared ledger underneath both. That single requirement — which wasn't explicit in the original ask, but became obvious once actually reasoning through what "real cost governance" should mean — flipped the decision to option 2: a standalone repo, agent-finops, matching how every other capability in this org is already its own single-purpose service (see ADR-011).

Option 3 (buy) was never seriously on the table here — cost metering needs to understand each consumer's specific LLM providers and per-model pricing deeply enough that a generic vendor FinOps tool wouldn't fit without as much integration work as building it, while giving up control over exactly how budget breach enforcement connects to each consumer's own kill-switch/ dispatch-halt mechanism (see system-design/01 for why that enforcement design needed to stay consumer-owned).

The interview-ready summary

Ask what cross-consumer question, if any, this capability needs to answer. If there is one and it's real, build a shared service — embedding will structurally never answer it. If there isn't one, embedding is fine and a shared service is premature complexity. Buy only when the capability is genuinely undifferentiated and doesn't need deep domain integration.

What's expected at each level

Mid-level: names the three options generically (build/embed/buy) without a clear decision rule between them.
Senior: identifies the real deciding question — is there a genuine cross-consumer requirement — for a given, stated scenario.
Staff+: describes a real case where the decision changed mid-plan once a requirement became clear, and explains why that specific requirement forced the shared-service option.
Principal: can articulate when "buy" fails even for a seemingly commodity capability — deep domain-integration need, or the vendor relationship itself becoming the new coupling problem.