Product teams make build-or-buy decisions constantly, even when they do not call them that. Authentication, payments, search, analytics, content management, AI models, messaging, scheduling, and reporting can all be built internally or purchased from someone who has already done the work.
The decision is rarely binary. Most useful systems are a combination of owned product logic, external services, and integration code that keeps the relationship manageable.
Build what makes the product meaningfully yours. Buy what is expensive to reproduce and ordinary to your customer. Integrate so either choice can change.
Start with differentiation
I begin with a simple question: if this capability is excellent, will customers choose or keep the product because of it?
If the answer is yes, the team probably needs meaningful ownership. That does not require building every dependency from scratch. A company whose advantage is scheduling may still use a managed database and an external email service. It should own the scheduling rules, the domain model, and the experience that makes those rules useful.
If the capability is expected but not differentiating, a mature service can save months of work. Few customers choose a business application because its team wrote its own payment vault.
Include the full cost of ownership
Building has costs beyond the first release: maintenance, security, monitoring, support, compliance, documentation, and the opportunity cost of features the team did not build instead.
Buying has costs beyond the subscription: integration, usage pricing, operational limits, vendor outages, contract changes, data export, and the effort required to leave.
I compare both over a realistic period and include the people who will operate the decision. A service that saves two engineers six months may be a bargain. A service that forces support to repair data by hand every week may not be.
Look closely at the exit cost
A vendor relationship is healthiest when leaving is possible. Before adopting a service, I want to know whether data can be exported in a useful format, whether identifiers can be mapped, whether business rules are trapped in proprietary configuration, and whether the integration can run in parallel with a replacement.
Exit cost does not need to be zero. It needs to be understood. A deeply embedded provider may be the right choice when it delivers major value. The mistake is discovering the dependency only after pricing, reliability, or product direction changes.
Separate the product from the provider
Integration code should translate between the language of the product and the language of the vendor. The rest of the application should not need to know every field name or error code in a third-party API.
A clear adapter makes testing easier and replacement possible. It also keeps vendor limitations from quietly becoming business rules. When the provider changes an API, the impact has a boundary.
This is especially important with fast-moving AI services. Model names, context limits, pricing, and tool behavior change. A product designed around one provider's request format inherits that provider's roadmap. A product designed around its own capabilities can choose the best implementation over time.
Match control to consequence
The more consequential the capability, the more control and visibility the team needs. That may favor building, or it may favor a specialized vendor with stronger security and compliance than the team could produce alone.
Consider failure. What happens when the service is slow or unavailable? Can the product degrade gracefully? Can work queue for later? Is there a manual path? How will the team know which customer records were affected?
A feature that sits on the critical path needs a fallback and an operating plan, regardless of who wrote the code.
Use a reversible pilot
When the answer is unclear, I avoid turning uncertainty into a permanent architecture decision. Define a narrow interface, test the service with representative data, measure cost and quality, and keep the first implementation replaceable.
The pilot should answer the questions that matter: Does it meet the workflow? Can it handle the edge cases? Is the documentation accurate? How does support respond? Does the pricing model fit actual usage? Can we observe and recover from failure?
A proof of concept is useful only if it tests the risks that would matter in production.
A framework I use
I work through seven questions:
- Differentiation: Is this part of why the product wins?
- Capability: Can the team build and operate it well?
- Time: What opportunity disappears while we build it?
- Risk: What happens when it fails or behaves incorrectly?
- Data: Who controls the records and how do they move?
- Economics: What does the decision cost at realistic usage?
- Reversibility: How hard will it be to change our mind?
The result may be build, buy, or a hybrid. The important part is that the decision follows the product strategy instead of a developer's urge to build everything or a deadline's urge to outsource everything.
Good architecture creates leverage. Sometimes that leverage comes from owning the code. Sometimes it comes from choosing a strong service. Most often it comes from knowing which is which.