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."

Executive summary

30-second thesis

I'd build a shared service only where it creates durable differentiation or unavoidable control. Otherwise buy — and spend energy on the seams that matter, not reinventing commodity plumbing.

2-minute answer

Score differentiation, control needs, total cost of ownership, talent, and exit options. Prefer buy for undifferentiated plumbing. Prefer build when policy, data gravity, or product UX is the actual moat. Thin shared library vs thick shared service is a second decision — policy enforcement often wants a service with an audit trail; notifications might be a library or a vendor.

What I'd refuse: building a platform nobody asked to adopt, or staying loyal to a bad shared service because of sunk cost. Write kill criteria and migration cost up front. On-call load when consumers outnumber builders is part of the decision, not an afterthought.

Quantitative trade-offs

Decision	Trade-off and reversal evidence	Evidence class
Control vs speed	Build increases control and slows first delivery; reverse buy→build when vendor limits block a non-negotiable invariant.	H
Shared platform vs team autonomy	Shared services reduce duplication; reverse when platform SLOs block product velocity without a self-serve escape hatch.	H
Vendor lock-in vs integration cost	Deep buy can lock; thin adapters raise near-term cost. Reverse lock-in tolerance when switching cost exceeds differentiation value.	H

Numbers and thresholds in interview delivery should be labeled H unless the candidate can defend a measured baseline. Open repositories are O; researched public patterns are R. Do not upgrade O/R into employer P adoption.

Migration and rollout

Build/buy is a decision process, not a deploy script — but if you buy, migration still matters.

Write the decision record: default, alternatives, reversal evidence, TCO assumptions (H labeled).
If buying: spike integration + exit criteria before enterprise agreement.
Dual-run critical path against the incumbent for a defined soak.
Cap blast radius: one product first, not org-wide day one.
Reversal plan funded up front — orphaned buy with no exit is how you get locked in.

Org ownership and operating model

Architecture council / Principal owns the build-vs-buy decision standard.
Platform owns shared-service SLAs if build.
Procurement / vendor mgmt owns buy commercials and exit clauses.
Security owns third-party risk review.
Finance owns TCO model honesty — no theater savings.

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.

Staff+/Principal signal rubric

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.

Follow-up questions to expect

What evidence would reverse your default?
What is the rollback path and who owns it?
What do you intentionally skip in 45 minutes?