Build vs Buy: A Framework for Technology Decisions

The build vs buy decision is one of the most consequential recurring technology decisions organisations make, and one of the most frequently made poorly. Teams that build underestimate the ongoing cost of maintenance, support, and enhancement. Teams that buy underestimate the cost of customisation, integration, and the constraint that comes from a vendor's product roadmap controlling a capability that matters to the business. The framework that produces good decisions addresses both failure modes.

The first question is whether the capability provides competitive differentiation. If the answer is genuinely yes, building may be justified even when comparable vendor products exist, because the organisation needs to control how the capability evolves. If the answer is no, which is true more often than internal advocates admit, buying a vendor product that handles the capability adequately is almost always more cost-effective. Most ERP, CRM, HRIS, and productivity functions do not differentiate and should be bought, not built.

Total cost of ownership over the expected lifetime of the solution is the most useful financial comparison. Build costs typically include: initial development, which is usually underestimated; integration with existing systems; ongoing maintenance as the underlying platform, dependencies, and security requirements evolve; and the organisational capability required to maintain a technical asset. Buy costs include: licence or subscription fees; implementation and customisation; integration; vendor support fees; and the potential cost of migration if the vendor relationship ends or the product is discontinued.

The maintenance burden of built solutions is systematically underestimated. A custom application built by a team that subsequently changes composition requires whoever inherits it to understand code they did not write, in a technology stack that may no longer be the organisation's primary choice. Dependencies on third-party libraries, APIs, and services require ongoing attention as those external components evolve. Security vulnerabilities in custom code require an internal response rather than a vendor patch. These costs are real but invisible at build time.

Lock-in risk applies to both options but in different ways. Buying from a vendor creates dependency on that vendor's roadmap, pricing decisions, and business continuity. Building creates dependency on the technology choices made at build time and the team that made them. Neither dependency is inherently fatal, but both need to be understood and managed. The relevant questions are: what happens if the vendor is acquired or discontinues the product, and what happens if the technology stack becomes obsolete or the team that built the solution is no longer available.

The decision should also account for organisational capacity. Building requires not just initial development capability but sustained product management, architecture, and engineering attention. Organisations that choose to build without planning for ongoing ownership often find themselves maintaining a technical liability rather than a strategic asset. The build option is only viable if the organisation commits the resources to maintain what it builds at the level the business requires.