How should Product and Engineering decide whether to build, buy or reuse software?

A team can spend months building a standard capability, or buy a product that does not fit the service it must support. Reusing an internal platform can shorten delivery but can also introduce a queue or a fragile dependency. The choice affects capacity, customer experience and future ability to change.

Define the decision at the capability level

Describe the user problem, required outcomes, non-negotiable constraints, likely change rate and expected operating life. Separate what differentiates the product from what is common infrastructure. Product owns why the capability matters and how it ranks against other investments. Engineering clarifies architecture, data, security, integration and operational needs. A short decision frame prevents a polished demonstration or existing internal preference from narrowing the options too soon.

Compare established sourcing routes fairly

Building can provide tailored behaviour and control, but requires design, maintenance, support and security effort. Buying may accelerate access to mature functionality, while configuration, integration, contract terms and supplier dependency still consume capacity. Reusing existing code or platforms may save initial work, but creates ownership and upgrade questions. GOV.UK purchasing guidance explicitly asks teams to consider build, buy and combined approaches against user need. Its public-sector rules are not general obligations for every organisation; the comparison principle is useful more widely.

Test the options together on representative work

Product should examine whether each option supports the important user journey and whether its limitations change the proposition. Engineering should test an awkward integration, data migration, accessibility, performance, failure recovery and observability where relevant. Procurement, legal, security and operations should assess their own boundaries. Compare total cost over a realistic horizon, including licences, people, changes, support and exit. A small proof of fit may resolve the most consequential uncertainty before a large commitment. AI may help compare documentation, but vendor claims and generated summaries still need direct verification.

Make ownership and exit explicit

A sourcing decision is incomplete without named owners for operation, upgrades, incidents, supplier management and data. Record why the selected route was chosen and what evidence would trigger reconsideration. Avoid treating “buy” as transfer of product accountability: Product still owns the customer outcome, and Engineering still owns how the capability works within its system. If the decision depends on one supplier or internal platform, consider portability, data export and contingency. Revisit assumptions as usage, cost, regulation or architecture changes.

Example

In a hypothetical membership service, the team needs identity verification for a new journey. Product defines the user and fraud outcomes. Engineering compares an internal component, a commercial service and a bespoke build against integration, failure handling, data retention and future change. Security and procurement review the external option. The team chooses a commercial service for a limited journey, assigns an operational owner and records the conditions that would justify replacing it.

FAQs

• Does buying automatically release engineering capacity?

  No. Integration, configuration, assurance, support and supplier change still require engineering work.

• When should a team reuse internal software?

  When it meets the need with an owned interface, support model and upgrade path; the apparent saving should include dependency cost.

• Should a strategic capability always be built?

  Strategic importance alone does not settle the route. Compare required control and differentiation with available products, lifecycle cost and delivery risk.