The article makes some good points, but the title is somewhat clickbaity and reductive. Blanket statements such as "Buy don't build" are unlikely to be a good rule-of-thumb to follow imho.<p>However, at the end, a somewhat more sensible advice is presented:<p>> I suggest that you prioritize buying to building, unless building will provide a real sustainable advantage for the business.<p>I generally only buy things to save time when I really don't have it, and usually as a temporary solution. Buying isn't an all-in or all-out solution. There are many levels at which you can decide to either buy or maintain the thing yourself. In a lot of average/usual situations, reading how to properly setup the service rather than just buying it from x-as-a-service will provide valuable learning not just for the setup itself, but also for tooling used around it, which will make developers even happier and more productive. For example, I wouldn't buy Redis/Elasticsearch as a service if I can spare a couple of days to read how to set it up (and of course there are always exceptions). Care about security first, then efficiency. It will take time, but it's not as difficult as it's made to seem.<p>Quick example, a few years ago, I witnessed a company save more than 80% of their hosting cost by switching from Heroku to a simple EC2/Ansible setup. They're still buying, but there are levels. Also, it helps to know what are the actual requirements when you're buying.<p>Thinking that buying everything as-a-service will save time is a misconception imo, as you'll likely end up having to spend time reading the docs of whatever you're buying. Decision changes will also cost more time because unless that service was using an open standard, you'll likely end up having to change a few things.<p>There's great value in learning open standards and how to automate setups. With that being said, no one can learn everything at once, so if the need is urgent and you're short on time and have properly studied the financial model of the service, yes, buying is a good option.<p>Not related to this, but I've been having a lot of fun messing around with Nomnad. I've also learned some very interesting things about how docker networking work because of it.