Build vs Buy: A Decision Framework for Business Technology

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.