Build vs Buy Is an Exit-Cost Decision

Aug 29

By

technical leadershipplatform engineeringcloud economicsvendor risk

“Build or buy?” is usually presented as a feature and price comparison. That framing misses the hardest part: whichever path you choose, the company still owns the customer outcome.

A managed database can remove patching work; it does not remove responsibility for recovery objectives, schema design, connection pressure, or a regional dependency. An AI API can remove model serving; it does not remove evaluation, privacy, cost, or fallback policy.

The governing invariant is:

Outsourcing execution never outsources accountability.

Start with differentiation

Build when the capability encodes a product advantage or a control you cannot delegate. Buy when the capability is necessary but does not distinguish the product—and a vendor can operate it materially better.

That principle is necessary, but not sufficient. Identity, billing, observability, workflow, search, and AI inference often begin as commodities and later become deeply embedded. The evaluation must include the future cost of changing direction.

Compare total ownership, not subscription price

Use the same cost model for both options:

annual cost = license or infrastructure
            + implementation
            + integration maintenance
            + on-call and incident cost
            + security and compliance work
            + migration and exit reserve
            + opportunity cost

Internal software is not free because engineers are already employed. Vendor software is not cheap because the first invoice is small. Model the cost per useful business unit—per active tenant, million events, successful workflow, or evaluated model response—at current and plausible future scale.

Make failure ownership explicit

Ask what happens at 02:00 when the dependency is slow, inconsistent, or unavailable.

QuestionRequired answer
Who detects failure first?named monitor and owner
Can the product degrade?explicit stale, queue, or fail-closed policy
Can support inspect state?audit and diagnostic interface
Is recovery tested?evidence, not an SLA link
What is the vendor escalation path?severity and response contract
Can we reconcile ambiguous outcomes?stable operation identity

A vendor SLA is an input to your reliability model, not your product guarantee. If a 99.9% dependency is synchronously required by every request, your service cannot honestly promise more without redundancy or degradation.

Price the coupling

Coupling is not only API syntax. It includes:

  • proprietary data models and workflow semantics;
  • identity and authorization embedded in the vendor;
  • historical data that cannot be exported completely;
  • operational knowledge held only in vendor dashboards;
  • features whose behavior cannot be reproduced elsewhere;
  • egress, contract, and migration timing constraints.

The most dangerous lock-in is semantic. Replacing an SDK is easy; recreating five years of authorization decisions or workflow history is not.

Keep your durable domain identity outside the vendor. Store the mapping from internal IDs to vendor IDs. Capture the minimum event history needed to reconcile. Wrap only the semantics for which you have a plausible second implementation; do not build an imaginary universal abstraction.

Design a credible exit

An exit plan is an architectural asset. It should specify:

  1. the data export format and tested retrieval time;
  2. the maximum acceptable dual-running period;
  3. the application boundary where traffic can be switched;
  4. reconciliation between old and new systems;
  5. contractual notice, deletion, and audit requirements;
  6. the condition that would justify paying the migration cost.

Not every dependency needs hot portability. A payroll vendor may justify a planned manual migration. A provider on the payment authorization path may require live routing and idempotent failover. Spend portability effort in proportion to business exposure.

Use a decision scorecard, not a magic score

Scorecards improve questions but should not hide judgment. Review at least:

  • strategic differentiation;
  • time to validated customer value;
  • five-year unit economics;
  • reliability and degradation control;
  • security and data classification;
  • integration depth;
  • operational capability of your team;
  • exit cost and time.

Write the assumptions next to every number. A weighted total without assumptions produces false precision.

Conclusion

Build versus buy is not an identity test for an engineering organization. Strong teams buy aggressively where ownership adds no advantage and build deliberately where control creates value.

The mature question is: which option gives us the best customer outcome, at an acceptable operating cost, with a failure model and exit path we can actually own?

References

>