The best way I've heard this put to me was this: "Your business has some special selling point where it stands out, the reason it's unique and people should buy your thing. Your business has hundreds of bog standard things it needs to do. You only have so much development time; spend it on the stuff that makes your company important and not on the stuff that already has perfectly good solutions sitting on the shelf."
Yup, this is the version that makes sense to me, with one addition:
If a component is high cost, tightly integrated with the rest of the system you're building, and difficult to design, you will need to become an expert on it just in order to evaluate suppliers and make good purchasing decisions.
Then (a) In order to become an expert on something, you need to do it yourself for a while; and (b) if you're an expert on it and have made it for a while, you might as well continue.
Thus: for high cost, tightly integrated, difficult to design parts: build, don't buy.
If a component is a major part of the value you're providing, it's sort of the same situation: you need to be an expert on it to safely buy it, and then you might as well build it indefinitely.
Very true, but I've also seen the inverse where days were spent on configuring and troubleshooting an off-the-shelf solution (with associated technical debt around upgrades) where a small in-house ad-hoc process could solve it much easier.
The answer is not always obvious and being able to make the right call consistently is something I consider a sign of a great engineer.
> Your business has hundreds of bog standard things it needs to do. You only have so much development time [...]
True for startups. Not true for BigCo. Economically it's a balance between the cost of a dev customizing the cogwheel and the cost of pushing the organization toward a standard factory-made cogwheel.
