Build, buy, or integrate: a working decision matrix

Teams build things they should have bought and buy things that make them generic — usually not through bad judgement, but because no one framed the choice. There are three honest options for any capability, plus a fourth worth naming out loud: build, buy, integrate, or do nothing yet.

The two questions that decide most cases

Is it your differentiator? If a capability is why customers choose you, lean toward building — you don't want your edge constrained by someone else's roadmap. If it's table-stakes plumbing (email, accounting, storage), buy it and never think about it again.

Does something off the shelf fit ~80%? Then buy, and resist the urge to customise it into a bespoke liability. The last 20% is almost always a process change, not a code change — and adapting your process is far cheaper than owning a fork forever.

The option everyone forgets

Integrate. Most companies already own tools that each do part of the job. Connecting them so they behave as one system is frequently the highest-return, lowest-risk move available — and it gets skipped because it's less exciting than a new purchase or a new build.

Compare on the cost that hides

Decide on three-year total cost of ownership, not sticker price. "Build" hides its cost in maintenance; "buy" hides it in lock-in and per-seat scaling. Name both, and record a trigger to revisit — a seat count, a price change, a volume threshold — so the decision stays honest as you grow.

"Do nothing yet" is a legitimate, often correct answer — and always cheaper than a wrong build.

The build/buy/integrate matrix in the toolkit turns this into a scored, per-capability decision you can put in front of a board.