Build vs buy gets treated as a financial decision.
It's an architecture decision. The financial analysis is part of it, but it's the part that's easiest to compute and least important to get right. The expensive consequences are architectural, and they show up months after the decision is made.
You're not buying a service. You're buying a dependency.
When you adopt a managed service, you are not adding a component. You are adding a dependency.
A hosted queue. A cloud database. A third-party API.
The distinction matters because components are things you control and dependencies are things that control you.
The face changed, the dependency didn't. Twenty years ago it was "the database is down." Today it's "the model provider is down." Same sentence, different noun. The failure mode never moved. You outsourced a critical capability to a service you don't control, and one day that service wasn't there.
Every buy decision accepts that failure mode. The useful question is: when this service fails, what happens to my system, and have I designed for that?
Most teams do not design for it. They discover it during the first outage, and the discovery is expensive.
The total cost isn't the invoice
The financial analysis usually compares the cost of building and operating the thing yourself against the vendor's pricing. This is the easy calculation, and it's the one that gets all the attention.
The real cost has three components that rarely make it into the spreadsheet:
Integration cost. The service has an API. Your code calls it. That is the easy part. The hard part is semantic integration. Does the service's consistency model match your system's? Does its failure behavior match your assumptions? Does its data model fit your access patterns? The integration cost is the work of reconciling two systems that were designed independently, and it is always larger than the estimate.
Operational cost. Even when the vendor operates the service, your team operates the dependency. You need monitoring for the service's health. You need alerting for degradation. You need a fallback for outages. You need a relationship with the vendor for failures you cannot fix. This is operational work with less direct control.
Exit cost. Every buy decision has an exit cost. If the vendor raises prices, changes their API, degrades their service, or shuts down, you need to be able to leave. The exit cost is the work of replacing the dependency, and it grows as your system couples itself to the service's specific behavior. Most teams do not track exit cost. They discover it when it is too large to pay.
When buy is the right architecture
None of this means buy is wrong. It means buy is architecture, and it should be evaluated as architecture.
Buy is the right decision when the service is a commodity and the architecture is mostly the same regardless of vendor. A message queue, CDN, or standard database often belongs in this category. The build cost is real, and the buy cost is predictable enough to justify the dependency.
The failure mode also has to be tolerable. If the service goes down, the system should degrade in a way the business can survive: queue work, process it later, serve stale data, or disable a noncritical feature. If the failure takes down the system, the buy decision has become a critical-path architecture decision.
The exit has to be tractable too. If replacing the service would take six months and risk data loss, the team has accepted a much deeper commitment than the vendor invoice suggests.
The last point is where most teams get hurt. They buy a service that's easy to adopt, build on top of it for two years, and then discover that replacing it would require rewriting half the system. The exit cost grew silently, and now they're locked in. The vendor can raise prices, change terms, or degrade service, and the team has no leverage.
When build is the right architecture
Build is the right decision when the capability differentiates the product. If the thing you would buy is the thing customers actually value, building it is the product work. When intelligence is a commodity, the advantage is the part you own.
Build also makes sense when the failure mode is unacceptable. Critical paths deserve more control than rented dependencies can always provide. The same applies when integration cost exceeds build cost. A service that is close but wrong can create months of adapters and workarounds, and that hidden integration cost may exceed the cost of owning the capability directly.
The decision framework
The better framework asks: what am I committing to, and for how long?
Buying commits you to a dependency, an integration surface, and an exit cost that grows over time. Building commits you to an operational burden, a maintenance cost, and a set of decisions you get to keep making.
Both are architecture. Both have long-term consequences. The mistake is treating buy as the default because it's faster to start. Speed to start is the wrong metric. The cost lives in the years after, and that cost is architectural.
The one-line version
You're not buying a service. You're buying a dependency. The price is the easy part. The architecture is what you inherit.