You are correct in the fact that 'buy' doesn't mean zero cost. At scale both 'build' and 'buy' suffer from the same problem, overhead. 'Build' has the overhead

You are correct in the fact that 'buy' doesn't mean zero cost. At scale both 'build' and 'buy' suffer from the same problem, overhead. 'Build' has the overhead of the initial development, documentation, testing, the follow-on maintenance, refactoring, etc. If you have one 'build' item in your code base that's not a huge amount of overhead in the long term. If your entire code base is custom you have a scaling problem; you will end up spending a lot of your development effort on this overhead rather than revenue generating work. Ideally 'buy' lets you go further but you will eventually reach the same scaling problem. The overhead here is in research, prototyping, integration, bugs, workarounds, etc. As you have more and more external dependencies this overhead goes up until you are in the same boat as above. Also not all dependencies are created equally; some have more overhead than others. For background I do embedded software where basically everything is 'build'. When I say everything I mean file systems, network stacks, hardware abstraction layers, communication protocols, testing frameworks, and so on. I would estimate that roughly 90-95% of what my team does is maintain all of the 'build' pieces, none of which makes a profit but all of which are required for the features that do make a profit; we just don't have time to work on the latter unless we take more shortcuts in the former. So when you say that a 'build' solution takes < 1 engineer to maintain consider what that looks like in 5, 10, and 25 years. The overhead stacks up, the industry changes, institutional knowledge is lost, hiring and onboarding becomes more difficult, and so on. Of course my bias is in systems that last a long time where it's incredibly difficult to replace custom bits that have outlived their usefulness with third party bits.