The New Arithmetic of Make-vs-Buy: A Decision Framework for the Managed Services Era

A decade ago, the make-versus-buy conversation was comparatively simple. You either invested engineering time to build a capability, or you licensed software and ran it yourself. Today, a third option dominates: rent. Managed databases, managed queues, managed identity, managed everything — the cloud providers and their ecosystems offer to operate nearly every layer of your architecture for a metered fee.

This has not simplified the decision. It has relocated the difficulty from the question of 'who builds it?' to 'what are we actually committing to, and can we leave?'

Why the Old Calculus Fails

The classic framework compared build cost against license cost, plus a fudge factor for maintenance. That framework assumes you own what you buy. With managed services, you are rarely purchasing software — you are entering a dependency relationship whose costs are architectural, organizational, and financial, and whose exit terms are written by the vendor.

A more honest evaluation weighs four dimensions.

Dimension 1: Total Cost of Ownership, Including the Learning Curve

The sticker price of a managed service is the easy number. The harder ones are the integration effort, the operational retraining, and the ongoing tuning your team will perform anyway. A managed Kafka substitute may eliminate broker administration but introduce a new configuration language, new failure modes, and a new billing model that requires active management.

Worked example: A mid-market US fintech evaluating a managed search offering found the monthly fee modest but the data egress costs — driven by their reindexing patterns — tripled the effective price. The right answer was still 'buy,' but only after the egress model was understood and negotiated.

Dimension 2: Lock-In Risk, Priced Honestly

Every dependency carries switching costs; the question is whether they are proportionate to the value received. A managed object storage service with an open API is a shallow dependency. A proprietary workflow engine with vendor-specific DSLs is a deep one — leaving means rewriting business logic, not redeploying infrastructure.

A useful test: imagine the vendor doubles prices tomorrow. Could you migrate within two quarters? If the answer is no, you are not a customer so much as a tenant.

Dimension 3: The Learning Curve as a Strategic Asset or Liability

Building in-house develops institutional capability; buying rents someone else's. Neither is automatically correct. If the capability is core to your differentiation — the recommendation engine at a content platform, the matching logic at a marketplace — the learning curve is an asset worth funding. If it is undifferentiated plumbing, spending senior engineering time mastering it is a liability disguised as craftsmanship.

Dimension 4: The Exit Strategy You Write Before You Sign

The most disciplined teams draft the exit plan at the moment of adoption: which interfaces to wrap, which data formats to keep portable, which open standards to prefer at the edges. This is not paranoia; it is insurance priced in days of engineering rather than dollars.

Practical guardrails include:

• Wrapping vendor SDKs behind internal interfaces at domain boundaries.
• Preferring services with export paths and open wire formats.
• Re-running the dependency audit annually, because lock-in deepens quietly.

A Worked Decision: The Authentication Question

Consider a common dilemma — build an in-house identity service or adopt a managed authentication provider.

• Build: Full control, deep customization, but a permanently staffed security surface and a slower feature cadence.
• Borrow (open source, self-hosted): Control with community leverage, but you own the operations entirely.
• Buy (managed provider): Fastest time to market, expert-grade security defaults, but session data, user flows, and pricing all live on someone else's roadmap.

For most US product companies, the managed provider wins on time-to-market and security posture — provided the team wraps the provider's SDK, keeps user data exportable, and negotiates pricing headroom before growth makes the contract one-sided.

The Principle Beneath the Framework

Buy what is undifferentiated. Build what differentiates you. Borrow — open source, self-managed — where control matters more than convenience but uniqueness does not. And whatever you choose, decide your exit before the dependency decides it for you.

The managed-services era has not eliminated the make-or-buy decision. It has simply made the consequences of deciding carelessly both cheaper to incur and far more expensive to reverse.