The CTO's Framework for Build vs Buy Decisions
The build versus buy decision is among the most consequential and frequently revisited choices a CTO makes. Every capability the technology organisation needs — from customer relationship management to deployment automation, from data analytics to authentication services — presents this fundamental question: should we build it ourselves or buy (or subscribe to) a commercial solution?
The stakes are high in both directions. Building when you should have bought consumes scarce engineering resources on undifferentiated work, creating maintenance burdens that persist for years. Buying when you should have built creates vendor dependencies, limits customisation, and may fail to deliver the competitive advantage that proprietary technology provides. And the decision is rarely permanent — organisations frequently switch from bought to built (outgrowing a vendor’s capabilities) or from built to bought (realising the maintenance burden of a custom solution exceeds the cost of a commercial alternative).
A rigorous decision framework reduces the frequency of costly reversals and ensures that engineering resources are allocated to their highest-value use.
The Strategic Differentiation Axis
The most important dimension of the build versus buy decision is strategic differentiation. Technology capabilities exist on a spectrum from commodity to differentiating, and the position on this spectrum should be the primary driver of the build/buy decision.
Commodity capabilities are well-understood, widely needed, and do not create competitive advantage. Email systems, identity management, project tracking, HR systems, financial accounting, and CRM are commodity capabilities for most organisations. Building these internally is almost never justified — commercial solutions are mature, well-supported, and continuously improved by vendors whose entire business depends on their quality.
The exceptions are rare and specific: organisations whose core business is the capability in question (a CRM company should obviously build its own CRM), or organisations with genuinely unique requirements that no commercial solution can address (which is far less common than engineering teams believe).
Context capabilities support the core business without directly creating competitive advantage. CI/CD pipelines, monitoring infrastructure, data pipelines, and internal tooling fall into this category for most organisations. These capabilities are important — they enable the team to deliver effectively — but they are not what customers choose you for.
Context capabilities occupy the most nuanced position in the build/buy spectrum. The decision depends on the maturity of available commercial solutions, the degree of customisation required, and the organisation’s appetite for vendor dependency. When mature commercial solutions exist that fit the organisation’s workflow (GitHub Actions for CI/CD, Datadog for monitoring, Snowflake for data warehousing), buying is typically the right choice. When requirements are unique enough that commercial solutions require extensive customisation, building may be justified.
Differentiating capabilities are the technology assets that create competitive advantage. These are the algorithms, platforms, user experiences, and data capabilities that customers choose you for and competitors cannot easily replicate. Recommendation engines for media companies, trading algorithms for financial firms, logistics optimisation for delivery companies — these are the capabilities worth investing scarce engineering talent in building and maintaining.
The principle is simple: buy commodity, evaluate context, build differentiating. The challenge is that engineering teams consistently overestimate how many capabilities are differentiating and underestimate how well commercial solutions serve their needs.
Total Cost of Ownership Analysis
Beyond strategic differentiation, a rigorous total cost of ownership (TCO) analysis ensures that economic reality informs the decision.
Build TCO must account for: initial development cost (engineering time, which at fully-loaded enterprise rates of $150-250K per engineer per year is substantial), ongoing maintenance cost (typically 15-25% of initial development annually, covering bug fixes, security patches, dependency updates, and feature enhancements), infrastructure cost (hosting, scaling, monitoring), and opportunity cost (what the engineers building this capability could otherwise be working on).
Opportunity cost is the most underappreciated component. In organisations with more product ideas than engineering capacity — which describes nearly every technology organisation — every engineer assigned to building internal infrastructure is an engineer not building customer-facing features. The opportunity cost of a five-engineer platform team building a capability that could be purchased is not just their salaries but the features, improvements, and competitive advantages they could have delivered.
Buy TCO must account for: licence or subscription fees (which escalate over time, sometimes dramatically at renewal), integration cost (connecting the commercial solution to existing systems), customisation cost (adapting the solution to organisational requirements), training cost (bringing teams up to speed), and switching cost (the expense and disruption of changing vendors if the relationship deteriorates).
Vendor pricing models deserve particular scrutiny. Per-seat licensing scales linearly with organisational growth and can become expensive at enterprise scale. Usage-based pricing aligns cost with value but can produce unpredictable expenses. Multi-year contracts provide discounts but reduce flexibility. Understanding the long-term pricing trajectory — including anticipated price increases, additional modules, and growth-driven scaling — is essential for honest TCO comparison.
The comparison must use the same time horizon. Build costs are front-loaded (high initial development investment, lower ongoing costs), while buy costs are more evenly distributed (subscription fees accruing over time). A three-year TCO comparison often favours buying; a ten-year comparison may favour building. The appropriate time horizon depends on how long the capability is expected to be needed and how stable the requirements are.
The Decision Framework in Practice
A practical build/buy decision framework evaluates each capability across five dimensions, scored and weighted according to organisational priorities.
Strategic Differentiation (Weight: 30%): Does this capability create competitive advantage? Score high for differentiating capabilities (build), low for commodity capabilities (buy).
Commercial Solution Fitness (Weight: 25%): How well do available commercial solutions meet the organisation’s requirements? Score high when solutions fit well (buy), low when significant gaps exist (build).
Total Cost of Ownership (Weight: 20%): Which option is more cost-effective over the appropriate time horizon? Score based on TCO comparison, accounting for all cost components.
Time to Value (Weight: 15%): How quickly does the organisation need the capability? Commercial solutions typically deliver faster than custom development. Score high when speed is critical (buy), low when the timeline is flexible.
Risk Profile (Weight: 10%): What are the risks of each option? Vendor risk (dependency, pricing, continuity) versus build risk (scope creep, maintenance burden, talent dependency). Score based on the organisation’s risk tolerance and the specific risks identified.
The weights are illustrative — each organisation should calibrate based on its strategic priorities. The framework’s value is in forcing structured evaluation rather than relying on the technical team’s instinctive preference (which typically favours building) or the procurement team’s instinctive preference (which typically favours buying).
Common Decision Anti-Patterns
Several recurring anti-patterns lead to poor build/buy decisions.
“Not Invented Here” syndrome drives engineering teams to build capabilities that commercial solutions serve perfectly well. The rationale often involves claims of unique requirements that, upon examination, are modest customisations that commercial solutions can accommodate. The underlying motivation is usually the engineering team’s preference for building interesting technology over integrating commercial products.
“It’s just a small project” underestimates the lifecycle cost of custom-built software. The initial build may indeed be a small project. But the ongoing maintenance — security patches, dependency updates, performance tuning, feature requests, documentation, on-call support — accumulates over years. Every custom-built component becomes a permanent maintenance obligation.
“The vendor will never add that feature” assumes that commercial solutions are static. In practice, commercial vendors with competitive markets continuously improve their products, often adding capabilities that organisations assumed they would need to build. The feature that is missing today may be on the vendor’s roadmap for next quarter.
“We can always replace it later” underestimates switching costs. Custom-built systems accumulate integrations, customisations, institutional knowledge, and operational procedures that make replacement expensive and risky. The temporary solution often becomes permanent, making the initial decision more consequential than anticipated.
Ignoring the vendor market makes build decisions without evaluating available commercial solutions. Before committing to building any capability, the CTO should ensure that the team has conducted a thorough market evaluation, including emerging solutions that may not be on the established vendor lists.
Conclusion
The build versus buy decision is a strategic allocation of the organisation’s most valuable resource — engineering talent. Every hour spent building commodity or context capabilities is an hour not spent on the differentiating technology that creates competitive advantage.
For CTOs in 2022, the framework is clear: buy commodity capabilities from mature commercial solutions, carefully evaluate context capabilities against commercial alternatives, and reserve custom development for the truly differentiating capabilities that define the organisation’s competitive position. Apply rigorous TCO analysis, resist the anti-patterns that distort decision-making, and revisit decisions periodically as both organisational needs and commercial solutions evolve.
The CTO who allocates engineering resources with strategic discipline — building only what creates genuine competitive advantage and buying everything else — will outperform the CTO who allows engineering preferences to drive technology portfolio decisions.