What is Build versus buy?
The decision is almost never about whether your team could build it. It is about what else they would not be doing for the six to twelve months it takes them to learn what somebody else already knows.
A competent internal team can build most of what is discussed on this site, and arguing otherwise would be both wrong and transparently self-serving. The real comparison is a schedule and an opportunity cost: the first version usually works, and then the gap between it and something that survives a real working week is where the months go - the input quality nobody sampled, the permission model that disagrees with itself, the adoption that a pilot never had to earn.
Which is why the honest framing is not either-or. The judgment - which problem, in what order, scoped to what measurable outcome - is worth buying whoever builds it, and it is the cheapest part of the whole exercise. Building afterwards with your own team is a perfectly good outcome, and the audit is explicitly allowed to conclude that.
| On this | Build versus buy | Comparing a licence price against salaries |
|---|---|---|
| What the comparison counts | Time to a working system, and what the team stops doing | Two numbers that are not measuring the same thing |
| Where the estimate usually breaks | Stated up front: data quality, permissions, adoption | Discovered at month eight |
| A legitimate answer | Build it yourselves, having scoped it properly first | Whichever number was smaller |
- When it is the right answer
- Before the estimate, not after. The question that settles it is what the team would have shipped instead, and nobody asks that once a build is already under way.
Start here
If a term here is the one your board paper turns on, ask us about it.
We will send the entry, the evidence behind it, and the honest note about where it does not apply.
You get a reply within one working day, from the engineer who would do the work - not a sales sequence.