Build vs. Buy vs. Partner Decision Template

Build when the capability is a core differentiator, when no vendor offers adequate functionality, when data sovereignty requirements prevent third-party usage, or when the long-term maintenance cost of buying exceeds building. If the capability touches your product's core value proposition, building usually wins.

Underestimating the ongoing cost of building. The initial build is 20-30% of the lifetime cost. Maintenance, upgrades, security patches, scaling, and on-call burden accumulate for years. Conversely, teams underestimate vendor lock-in and switching costs when buying. The [Product Strategy Handbook](/strategy-guide) covers how to think about technical debt from these decisions.

Partnerships work best when the partner's core competency complements yours, the integration is deep enough to feel native, the business model alignment is clear (revenue share, co-marketing), and there is a contractual framework for the relationship ending. Evaluate partnerships the same way you evaluate vendors, with the added dimension of relationship management cost.

Always. Engineering teams have the most accurate estimate of build effort and maintenance burden. They also know the existing tech stack constraints that may favor one option over another. Present engineering with the requirements and let them provide independent estimates before sharing vendor pricing. This prevents anchoring bias.

Acknowledge it directly. Engineers prefer building because it is more interesting and gives more control. That preference is valid. But frame the conversation around opportunity cost: "If we spend 6 months building analytics, what features do we not ship?" The [RICE framework](/frameworks/rice-framework) helps quantify the opportunity cost by scoring the deferred work. ---