Build, Buy, or Partner
Choose the sourcing model by differentiation, market maturity, and your ability to operate it.
To an executive
Build only what sets you apart, buy what everyone needs, and partner when speed or skills are short. This keeps scarce talent on work that wins customers.
To an engineer
For each capability, ask if it differentiates and if you can sustain running it. Buy utilities and adapt your process to them. Build where you want to outdo competitors.
The idea
Every capability can be sourced in three broad ways:
- Build when it differentiates you and you can sustain it: you have, or can hire, the skills to build and run it for years.
- Buy when the market offers a mature product for a capability that does not differentiate you.
- Partner when you need a capability faster than you can build it, or need expertise you do not have, and can share the risk.
Martin Fowler frames the first cut as utility versus strategic. For a utility function, buy a package and adapt your processes to it rather than customising it heavily. For a strategic function, where you do not want competitors to have the same software, build it and make it as good as you can.
It is not a one-off decision. Capabilities move between categories as markets mature and strategy shifts.
Why it works
It ties engineering effort to advantage. Scarce people go to the work that wins customers, not to rebuilding what the market already sells.
It respects your ability to operate. A build you cannot sustain, or a partnership you cannot manage, fails however strategic the capability is.
It makes the exit part of the choice. Thinking about how you would leave a vendor or partner shapes the contract, data ownership and integration from the start.
Where it applies
- Sourcing strategy for the capability map, deciding the default model for each capability.
- Vendor selection, where the question is whether to buy at all before comparing products.
- Operating model design, where partners and outsourcers become part of how the organisation runs.
- Portfolio reviews, finding in-house systems that the market now offers as products.
How to apply
- Classify the capability as differentiating (strategic) or utility, ideally on a capability map.
- Check market maturity, for example with a Wardley map: how evolved is this capability, and how many credible suppliers are there?
- Assess your ability to build and sustain it, including skills, funding and operations.
- Compare total cost of ownership for each option, including integration, data ownership, vendor viability and exit.
- Set a review point, because today's strategic build may be tomorrow's utility.
Example scenario
A logistics firm planned to build its own route optimisation. It was clearly core to its proposition, but the team had no optimisation specialists and the business needed results within months.
The enterprise architect recommended partnering with a specialist, with contract terms that kept the firm's data and models portable and a plan to build in-house expertise alongside. The partnership delivered results within a quarter, and two years later the firm brought the capability in-house as planned.
Questions to ask
- Does this capability differentiate us in our customers' eyes, or is it a utility?
- How mature is the market for it, and how many credible suppliers are there?
- What would it cost to exit if this choice proves wrong?
When not to use it
- Regulated or sovereign capabilities, where the sourcing model is set by law or policy rather than by strategy.
- Tiny, short-lived needs, where the analysis costs more than simply picking a tool.
How it misleads you
Defaulting to "buy" for everything, and ending up with a fragile patchwork of vendors and integrations where the integration itself becomes the hardest thing to change. The opposite failure is building utilities out of pride and calling them strategic.
In the wild
Further reading
Last reviewed · Suggest an improvement