Framework library · Technology management
Build, buy or partner
Every capability a business needs can be built by its own people, bought as a product, obtained through a partner or assembled from open source. The right route depends less on price than on whether the capability sets the business apart and whether it has the people to build and run it. Scoring the routes against the same weighted criteria makes that judgement explicit and open to challenge.
Use it when
- A capability or system needs replacing, and in-house teams, vendors and integrators all have a case.
- A partnership has been proposed and you want to test it against building or buying before anyone signs.
- Engineering capacity is scarce and you need to decide where it goes and what to source elsewhere.
Avoid it when
- The capability is a commodity with a clear market price. Buy or rent it and spend the analysis elsewhere. A Wardley map shows which components these are.
- The routes have not been scoped or costed. Scores on guesses look precise and are not. Work out the total cost of ownership first.
- The real choice is between suppliers, not between routes. Run the supplier selection with a weighted decision matrix.
How to run it
Define the capability and the result it must deliver
"Take orders from retail providers through industry-standard interfaces, with activation in under a day" is a capability. "A new order system" is a solution.
Describe each route concretely
Who would build it, which product you would buy, which partner and on what terms, which open-source project and who would support it. A vague route scores whatever its sponsor hopes.
Weight the criteria before scoring
Agree which criteria matter most for this capability. Differentiation weighs heavily for what sets you apart; time and cost weigh more for what does not.
Score each route from 1 to 5
Score cost and risk as they are, with 5 the highest, and the tool turns them round so that lower is better. Write the reason for each score in the note.
Test the ranking against the weights
Move the two largest weights by one point each. If the leader changes, the decision rests on that judgement, and the discussion belongs there rather than on the scores.
Record the decision and what would reopen it
Write it up as an architecture decision record, with the price, date or capability change that would send you back.
Work through it
Answer the questions below, or load the worked example to see a finished one. The drawing updates as you type. Export the result as a PowerPoint deck, a Word document, an Excel workbook, a PDF or plain text.
What you type stays in this browser, so you can close the page and come back to it. It is not sent to Blue Prysm or anyone else, and the exports are made here, on your device. Privacy policy.
Mistakes to avoid
- Comparing a build estimate that covers development only with a purchase price that covers five years. Put every route on the same total cost basis.
- Building something that sets you apart in theory but not to customers. Ask whether a customer would notice if you used the same product as your competitors.
- Forgetting the cost of leaving. A partner or product that holds your data or your customer relationship is cheap to enter and expensive to exit. Score that under risk.
- Treating open source as free. Someone has to integrate, secure and support it, and that cost belongs in the score.
Where it comes from
No single originator. Laurence Capron and Will Mitchell set out the choice between building internally, borrowing through contracts and alliances, and buying through acquisition in Build, Borrow, or Buy: Solving the Growth Dilemma (Harvard Business Review Press, 2012). In technology decisions, buying usually means licensing a product rather than acquiring a company, and open source adds a fourth route. Source.
Use it with
Further reading
Work through it with us
The frameworks here are free to use as they stand. If you would rather work through the question behind this one with us, these are the ways an engagement starts.