The buy-vs-build conversation is older than the cloud, and it keeps coming back because the answer keeps changing. The landscape of credible SaaS, the cost of senior engineering, the shape of partner ecosystems, and the rate at which platforms commoditize previously bespoke work are all moving. The question worth answering is not the philosophical one. It is the operational one: for this specific capability, in this specific organization, this year, which sourcing path actually wins?
Start From Differentiation
Harvard Business Review's strategy archive is filled with the same lesson, written a hundred different ways: build what differentiates, buy what does not. The question for any sourcing decision is whether the capability is part of the moat or part of the table stakes. Most organizations build too much of the second category and under-invest in the first.
The Four-Lens Framework
A useful way to score a sourcing decision is across four lenses, with weights tuned to the specific decision.
Differentiation
Does this capability differentiate the business in a way customers feel? If yes, lean toward build or strategic partner. If no, lean toward buy.
Total cost of ownership
Real TCO over a five-year window — license, infrastructure, integration, ongoing engineering, and the eventual replacement cost. Buy almost always understates integration; build almost always understates maintenance.
Time to value
Honest delivery dates, not the optimistic ones. Buy wins on time-to-value almost every time, which matters when the business case is time-sensitive.
Strategic risk
Vendor concentration, lock-in, supply chain exposure, and regulatory durability. Build trades cost for control; buy trades control for cost. Both have a risk shape.
Where The Partner Path Wins
The partner path — embedded engineering, fractional leadership, or co-build arrangements — is undervalued precisely because it does not fit the binary. Gartner's research on technology sourcing models has consistently found that partner arrangements outperform both pure build and pure buy in two specific situations: when the capability is differentiating but the in-house team lacks the depth to build it well, and when the business case is time-sensitive but the off-the-shelf fit is poor.
The Failure Modes
Build fails most often when the team underestimates the maintenance tax: the on-call rotation, the dependency upgrades, the security patching, the docs that nobody owns. Buy fails most often when the procurement decision precedes the workflow design: the tool gets selected, the workflow has to bend to the tool, and the tool quietly stops being used. Partner fails when accountability is fuzzy: the work gets done, but the institution does not learn from it. Each failure mode is preventable if it is named ahead of time.
A Scoring Rubric Steering Committees Can Use
Run each candidate sourcing path through the four lenses, score each on a 1–5 scale, weight by relevance to the specific decision, and let the resulting numbers anchor the conversation. The rubric does not make the decision. It forces the conversation onto common terms, which is most of the value. A McKinsey-style operations sourcing analysis is a useful reference for the underlying mechanics.
Key Takeaways
- Build what differentiates; buy what doesn't
- Evaluate sourcing on four lenses: differentiation, TCO, time-to-value, strategic risk
- Partner paths outperform pure build or pure buy in specific, identifiable conditions
- Build fails on maintenance tax; buy fails on workflow conformance; partner fails on fuzzy accountability
- Use a weighted scoring rubric to anchor the decision in shared terms
- Decide capability by capability, not as a one-size-fits-all sourcing posture