It's interesting that the whole article is pitched around a context where there is a basic assumption that there is a whole engineering team, devops etc., and t

It's interesting that the whole article is pitched around a context where there is a basic assumption that there is a whole engineering team, devops etc., and the question is about how their time is best utilized. But if you chose to buy instead of build everything most of that would not exist. So there's a paradox I see which is akin to the credit system where only people who don't need credit are offered it: you can only "afford" to buy instead of build when you have the engineering competence to build - that's when you can intelligently choose not to. On the other hand, if you lack the internal competence to build and for that reason choose to buy? That's when all the bad things happen. You're going to get screwed by your vendor - they are going to know you aren't technically capable of supporting yourself, they will give you stupid timelines, blown out costs, unreasonable constraints ("it has to have a 16 core, 256GB RAM server or we won't support it") etc etc. You will end up with the worst case of vendor lockin and a system everybody hates. So one of the pitches I make when people are making this decision is that you should be building at least some things, because the strategic cost of not doing that affects everything else you do.