# Which capabilities should you build, buy or obtain through a partner?

By Sean Everett · October 6, 2026

Choose a sourcing path for each capability by examining customer value, the control it needs and the work required to keep it useful. Include integration, ongoing ownership and the conditions that could change the decision.

Topics: Product strategy · Technology sourcing · Operating model

## Make the choice at the capability level

Break the proposed product into capabilities a customer or operator can recognize. For each, describe the required behavior and why it matters. A differentiated customer experience can depend on several ordinary components, so one sourcing decision for the entire product may conceal useful combinations.

The UK Government Digital Service's purchasing guidance connects build-or-buy decisions with user needs, available products and the organization's ability to support them. It also recognizes a combined approach. Apply that reasoning to each capability while keeping the government's procurement requirements within their own jurisdiction.

Ask where control creates customer value. Does the team need to change the underlying behavior frequently, or mainly configure a standard process? Write down the specific limitation that would justify custom development. A preference for owning code is insufficient without a corresponding product or operating need.

## Compare the responsibilities that remain

For a purchased capability, identify the integration, data movement, access configuration and support work the buyer still performs. For a custom build, identify who will maintain compatibility, handle failures and implement necessary changes after the initial delivery. Compare these responsibilities over the same operating period.

AWS's operational-excellence guidance recommends managed services to reduce operational burden and calls for operating procedures around their use. Treat that as a prompt to inspect which work actually moves to the provider. It does not establish lower total cost or suitability for every workload.

A partner arrangement needs an equally concrete boundary. Specify the capability contributed, the decisions each party controls and the knowledge the receiving team must retain. Ask the appropriate owners to resolve usage rights, change responsibilities and exit requirements before relying on the contribution in a customer promise.

## Record what would change the answer

Compare a small number of complete options against the same customer scenario. Include the transition from the current arrangement and the work needed if the option must later be replaced. Test the uncertain capability or handoff that is most likely to reverse the choice.

Give the decision a review trigger: a material change in supplier terms, a new bundled capability, a recurring integration problem or a product requirement the current path cannot support. Record the relevant dependency so the trigger is visible to someone with authority to reconsider it.

The resulting decision should name the chosen route, the responsibility retained internally and the assumption still being tested. Different capabilities can take different paths, provided the team can operate the combined customer experience and explain who owns each part when something changes.

## Related reading

- [Government Digital Service: Define your purchasing strategy](https://www.gov.uk/guidance/define-your-purchasing-strategy)
- [AWS: Operational excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operational-excellence.html)
- [Evaluating a platform through complete workflows](https://evergences.com/insights/workflow-based-platform-evaluation/)
- [Structuring a technical partnership](https://evergences.com/insights/research-partnership-product-delivery/)

Source: https://evergences.com/insights/build-buy-partner-capability/