Lesson 78: Build, Buy, or Partner: Platform vs. Point Solution Decisions

This lesson has been owed to you since Lesson 61, and it draws together threads from across this entire module. Lesson 61 first raised the question of whether a capability belongs at Layer 1 (built internally) or should instead be acquired through an external ecosystem. Lesson 62's API design discipline matters directly to how well a bought or partnered capability will actually integrate. Lesson 69's Friction Ledger established that internal platform investment carries real, often underestimated cost. Lesson 75's Moat Durability Matrix established that not every current capability is worth defending as though it were a genuine competitive advantage. Lesson 76's Integration Continuum addressed what happens once you've acquired a capability through M&A. Lesson 77's Portfolio Health Grid established that resources committed to any bet, including an internal build, deserve stage-appropriate scrutiny rather than momentum-driven continuation.

The build-versus-buy-versus-partner decision is one of the most consequential and most frequently mishandled decisions a product organization makes, because it is rarely approached as a single, explicit decision at all. Far more often, a capability simply gets built, by default, because building feels like the natural extension of what an engineering organization already knows how to do, without anyone ever seriously evaluating whether buying an existing solution or partnering with an external provider would better serve the company's actual strategic position. This default-to-build pattern, sometimes called "not invented here" syndrome, can consume years of engineering effort duplicating capability that was never going to differentiate the company in any meaningful way.

This lesson introduces the Capability Sourcing Matrix, this lesson's core mental model, to give you a structured way to make this decision deliberately, using the moat, migration, and portfolio disciplines this module has already built.

Learning Objectives

1
Explain why "not invented here" syndrome causes companies to default to building capabilities that would be better bought or partnered for.
2
Apply the Capability Sourcing Matrix to determine whether a given capability should be built, bought, or partnered for.
3
Identify the role of the Moat Durability Matrix in determining whether a capability is genuinely worth building internally.
4
Explain how the total cost of an internal build, including ongoing Friction Ledger and Sunset Runway maintenance burden, should factor into a sourcing decision.
5
Evaluate a proposed internal build decision for whether it is justified by genuine strategic differentiation or merely by organizational default.

This lesson assumes fluency with the Leverage Stack (Lesson 61), the Friction Ledger (Lesson 69), the Moat Durability Matrix (Lesson 75), the Integration Continuum (Lesson 76), and the Portfolio Health Grid (Lesson 77), since this lesson explicitly integrates all five into a single sourcing decision framework.

Why Companies Default to Building

"Not invented here" syndrome describes an organizational tendency to prefer building a capability internally over acquiring it externally, often for reasons that have little to do with genuine strategic advantage: internal engineering teams often find building more interesting and career-advancing than integrating a third-party solution, existing organizational structure and headcount naturally expand to justify more internal ownership, and there is a comforting illusion of control in owning a capability outright, even when that control provides no meaningful strategic benefit. This default is dangerous specifically because it consumes real resources — engineering time, ongoing maintenance burden per the Friction Ledger from Lesson 69, and opportunity cost against genuinely differentiating work — without any corresponding strategic return, since a capability that provides no competitive differentiation gains nothing from being built rather than bought.

The Capability Sourcing Matrix

This lesson introduces the Capability Sourcing Matrix, evaluating a capability along two dimensions: how central it is to genuine competitive differentiation, and how mature the external market's existing solutions for that capability already are.

A capability that is both genuinely core to the company's moat, per the Moat Durability Matrix from Lesson 75, and has no mature external solution available should generally be built, since building is the only way to obtain a capability that provides genuine differentiation and cannot be acquired otherwise. A capability that provides no meaningful differentiation and has mature, well-established external solutions available should generally be bought, since building it internally would consume resources duplicating something that offers no strategic return. A capability that is genuinely differentiating but where mature external solutions do already exist calls for a more nuanced partner approach, often integrating an external provider's capability while retaining differentiation through how that capability is applied, combined, or presented, rather than through owning the underlying technology itself. A capability that is neither differentiating nor well-served by mature external solutions should prompt a more fundamental question about whether the capability is genuinely needed at all, or whether the closest available external fit, however imperfect, is still preferable to an internal build with no strategic justification.

Total Cost of Ownership, Not Just Initial Build Cost

A sourcing decision evaluated only on initial build cost systematically underestimates the true cost of building, because it ignores the ongoing maintenance burden a built capability imposes — precisely the Friction Ledger concern from Lesson 69, since an internally built capability becomes, in effect, an internal platform that must be maintained, documented, and supported indefinitely, and precisely the Sunset Runway concern from Lesson 68, since retiring a built capability later, once dependents have accumulated, carries its own significant migration cost. A capability that seemed reasonably cheap to build in isolation can become considerably more expensive once its full lifecycle cost — ongoing maintenance, internal support burden, and eventual retirement difficulty if it's ever superseded by a better external solution — is honestly accounted for.

Revisiting Existing Builds Through the Portfolio Health Grid

The Capability Sourcing Matrix is not only relevant for new capability decisions; it should periodically be applied to existing internally-built capabilities as well, since a capability that was correctly built years ago, when no mature external market existed, may no longer justify continued internal investment if a mature external market has since developed. This connects directly to the Portfolio Health Grid from Lesson 77: an existing internal build should be evaluated with the same stage-appropriate, evidence-based rigor as any other ongoing bet, rather than continuing indefinitely simply because it already exists and reversing the decision would require politically difficult acknowledgment that a prior investment should now be reconsidered.

Common Mistakes to Avoid

Defaulting to build without seriously evaluating whether mature external solutions already exist

"Not invented here" syndrome causes many capabilities to be built internally by default, without a genuine market scan of available alternatives.

Evaluating a build decision using only initial development cost, ignoring ongoing maintenance and eventual retirement cost

This systematically understates the true cost of building relative to buying or partnering.

Assuming any capability the company has built must be strategically important, simply because resources have already been invested in it

Sunk cost should not substitute for an honest Moat Durability Matrix assessment of whether the capability is genuinely differentiating.

Treating "buy" as always cheaper and "build" as always more strategically valuable, without checking the specific quadrant a capability actually occupies

Buying a genuinely differentiating capability from an external vendor can hand a strategic advantage to any competitor who buys the same solution; building a non-differentiating capability wastes resources with no corresponding strategic gain.

Failing to periodically revisit existing build decisions as the external market matures

A build decision that was correct at the time it was made can become outdated as external solutions improve, and failing to revisit it wastes ongoing resources on maintaining a now-unnecessary internal capability.

Build, Buy, or Partner: Platform vs. Point Solution Decisions