dQuality insight
The visible price is rarely the full decision
Build-versus-buy discussions often begin with two numbers: an internal development estimate and a vendor subscription price. The lower figure appears to offer the obvious answer.
Neither number represents the commitment.
Building creates a product the company must continue to operate. Buying accelerates access to capability, but introduces integration work and dependency on another company's roadmap. Both options consume attention long after launch.
The real question is which option provides the right capability and control at an acceptable total cost and strategic risk.
Define the capability before comparing solutions
A weak evaluation starts with products. A stronger one starts with the business capability the company needs.
Describe the desired outcome without assuming a particular implementation. Instead of "we need a custom CRM," define which customer information must be captured, which teams need access, which workflows should be automated, and which decisions the system must support.
Separate requirements into three groups:
- Commodity needs: common functions where differentiation creates little value.
- Operational needs: workflows specific to how the company currently delivers its service.
- Strategic needs: capabilities that materially affect the customer proposition, learning speed, economics, or defensibility.
Custom does not always mean strategic. Reproducing an unusual process that exists because of historical constraints can preserve complexity rather than create an advantage.
Before choosing build or buy, ask whether the process itself should remain unchanged.
Compare total cost over a realistic horizon
A subscription price is not the total cost of buying, and an initial delivery estimate is not the total cost of building.
For a purchased product, include licensing, implementation, migration, integration, security and legal review, administration, training, vendor-specific development, and contract exit costs.
For a custom build, include discovery, delivery, infrastructure, security, maintenance, support, documentation, product ownership, key-person dependency, and opportunity cost from work the team will not deliver elsewhere.
Use a time horizon long enough to expose the operating model. The purpose is not to predict every future expense precisely. It is to prevent recurring obligations from disappearing behind a launch budget.
Price the integration surface
The value of software depends on how well it fits the surrounding system.
A vendor product may be quick to demonstrate but difficult to connect to identity, billing, analytics, reporting, or internal data. A custom product may integrate naturally with existing infrastructure but require the team to recreate mature administrative and compliance features.
Map the complete integration surface before making the decision. Identify data flowing into and out of the capability, the system of record for each entity, required permissions, failure behaviour, and ownership when information becomes inconsistent.
Pay particular attention to bidirectional integrations. They can create ambiguous authority and difficult recovery scenarios. If both systems can modify the same record, the evaluation should explain how conflicts are resolved and how changes are audited.
Integration risk is not simply an engineering concern. It affects customer support, financial reporting, operations, and the speed at which future products can change.
Evaluate strategic control
The right level of control depends on the role the capability plays in the business.
Buying is often appropriate when the requirement is mature, standardised, and not central to differentiation. Routine administrative systems rarely become more valuable because a company owns their source code.
Building becomes more defensible when the capability shapes the customer experience, encodes important operating knowledge, or enables a business model that available products cannot support.
Even then, control should be defined precisely. A company may need ownership of the workflow and customer interface without needing to own authentication, payments, search infrastructure, or messaging delivery. The most effective architecture may combine purchased foundations with a custom strategic layer.
Avoid slogans about ownership or lock-in. Identify the control actually required: data portability, interface flexibility, release timing, pricing logic, regional hosting, or replaceable components.
Make vendor risk explicit
Buying transfers some implementation work, but it does not transfer accountability for the business outcome.
Assess the vendor's stability, security, support, product direction, data practices, and regulatory fit. Review how the contract handles service changes, data export, termination, and continuity.
Roadmap alignment matters as much as current functionality. If the business depends on a feature the vendor considers peripheral, the gap may widen over time.
Plan an exit before signing. Determine what data can be exported, how long migration could take, and which integrations need replacement. This establishes the real cost of dependency.
Consider the cost of delay
The lowest-cost option may be wrong if it delays an opportunity. Conversely, a fast vendor implementation may slow later initiatives.
Model time in stages:
- Time to validate the workflow.
- Time to reach a reliable first release.
- Time to organisational adoption.
- Time to modify the capability after learning from use.
A lightweight purchased tool can test demand. A focused internal prototype can reveal whether a supposedly unique process is actually valuable.
Reversibility should influence the first step. Prefer experiments that produce evidence without forcing the final architecture too early.
Use a written decision record
A good decision should remain understandable later.
Record the required capability, options, cost assumptions, strategic criteria, risks, time horizon, and conditions that would trigger a review.
The final recommendation should be explicit:
- Buy when speed and mature commodity functionality outweigh the need for control.
- Build when the capability is strategically important and the company is prepared to own it.
- Compose when custom value can sit on reliable purchased foundations.
- Defer when the requirement is not yet understood well enough to justify either commitment.
Ownership is the real commitment
Build versus buy is not a question of whether the company pays engineers or a vendor. It is a choice about where the organisation wants responsibility to live.
Building means accepting responsibility for the capability's continued quality and evolution. Buying means accepting responsibility for managing dependency, integration, and contractual exposure.
The strongest decision is not the one with the cleanest spreadsheet. It is the one that makes those responsibilities visible, connects them to strategy, and preserves enough flexibility for the business to learn.
