A build, buy or partner decision asks how a product should obtain a capability. The answer depends on the competitive advantage it supports, the organisation's ability to deliver it and the full cost and risk of each option.
Building means developing and operating the capability internally. Buying means acquiring an available product or service. Partnering means sharing delivery or commercial responsibilities with another organisation. Some solutions combine all three.
Separate differentiation from operational importance
A capability can be essential without being a reason customers choose the product. Payment processing, for example, may be critical while a specialist provider supplies it well. Conversely, a distinctive capability may still depend on bought infrastructure.
Geoffrey Moore's core and context distinction is useful here. Core concerns differentiation, while context supports the business. Use that distinction to frame the decision, not to issue an automatic instruction to build or outsource.
Compare costs on the same basis
Suppose a fictional maintenance product needs routing capability. The table preserves a worked three year comparison using explicit assumptions. All figures are illustrative and undiscounted.
| Option | Included costs over three years | Subtotal |
|---|---|---|
| Build | £165,000 initially plus £33,000 in each of the next two years | £231,000 |
| Buy | £48,000 a year plus £30,000 initial integration | £174,000 |
| Partner | 20 per cent of attributable revenue of £200,000, £500,000 and £917,000 | £323,400 |
These subtotals do not settle the decision. Confirm whether support, hosting, upgrades, security review and exit work are included. A revenue share is particularly sensitive to growth and the contract's definition of attributable revenue.
Also name the work the internal team would defer. That opportunity cost matters, but avoid counting the same staff cost twice under different labels.
Test capability and service requirements
Create a short set of essential scenarios using representative data. For routing, these might include unavailable engineers, urgent jobs and unreliable connectivity. Ask each option to demonstrate how it handles the same situations.
Check integration effort, data access, incident response, commercial terms and the ability to leave. A low initial price can be outweighed by a difficult migration or a dependency the supplier will not support.
Make the decision revisable
An early product may buy a capability to test demand quickly and reconsider later. A growing product may find that operating its own capability is economical, or that a specialist has improved enough to replace an internal system.
Define a review trigger tied to evidence, such as usage cost, unmet requirements or a change in strategic importance. Include transition costs in any later comparison. Previous development spending is not recoverable, but the existing system's future value and costs remain relevant.
For a practical exercise, prepare a decision record with required scenarios, comparable costs, important risks and an exit plan. Recommend an option and name the assumption most likely to change the recommendation.
Where each syllabus puts it
The Pragmatic Framework uses this decision to address gaps in a complete solution to a market problem. The Product Strategy Practitioner course also examines how the capability supports the proposed advantage, resource allocation and commercial model.