.png&w=384&q=75){kind=small}
Build vs Buy: A Decision Framework for Business Technology
Build when the capability is your competitive advantage, when no off-the-shelf solution fits your workflow, or when platform lock-in is an unacceptable risk. Buy when the function is commodity (accounting, email, project management), when time-to-value matters more than customisation, or when the vendor's R&D investment exceeds what you'd spend building. Most businesses should build 10–20% of their stack and buy the rest.
Build vs buy is the most common technology decision growing businesses face, and the most commonly made poorly. The mistake isn't choosing build or buy. It's applying one answer to every situation instead of evaluating each decision on its own merits.
Build when: the functionality is your competitive advantage (if it differentiates you, own it), no existing solution handles your specific workflow (the workarounds cost more than building), you need complete data control (compliance, security, IP), or the integration cost of an off-the-shelf solution exceeds building from scratch.
Buy when: the function is commodity (email, accounting, project management — no competitive advantage in building your own), the vendor's R&D investment dwarfs yours (they have 50 engineers improving the product; you'd have 1), time-to-value is critical (buying is days, building is months), or the total cost of ownership (including maintenance, upgrades, security) favours buying.
The hidden cost of buying: integration, customisation limitations, vendor lock-in, and dependency on the vendor's roadmap. The hidden cost of building: maintenance, security, hiring, and the opportunity cost of engineering time spent on infrastructure instead of features.
Decision matrix scoring: for each capability, score it on differentiation (1–5), available solutions fit (1–5), integration complexity (1–5), and total cost of ownership over 3 years. Build when differentiation is high and solution fit is low. Buy when differentiation is low and solution fit is high.
Review the decision annually. A capability you bought last year might need to be built this year because your needs have outgrown the platform. A capability you built might now be better served by a mature SaaS product. The goal is right-sizing your build/buy ratio as the business evolves.
Frequently Asked Questions
For most businesses: 10–20%. This means commodity functions (email, accounting, project management) are bought, while core differentiators (customer-facing products, unique workflows, competitive data models) are built. Companies whose core product is technology may build 50–70% of their stack.
Include: initial cost (license/build), integration cost, training, ongoing subscription/maintenance, customisation, migration cost if you leave, and opportunity cost. Calculate over 3 years minimum. Most 'cheap' SaaS tools are expensive when integration and customisation costs are included.
This is a valid strategy called 'buy then build.' Start with an off-the-shelf solution to validate the need and understand requirements. When you outgrow it, you have real usage data to inform the custom build. Budget 2–3 months for migration and plan data export from the start.
Sources
- Harvard Business Review: Build vs Buy(accessed 2026-01-08)
Last updated: