Buy Don't Build

The mechanisms by which your product is marketed, sold and distributed are core to your business flywheel. For example, if you’re a B2B Saas, distribution is often way more important than the product itself.

So by the “core to our flywheel” standard you need to build your own email marketing software, your own version of salesforce CRM, your own analytics tool for triggering marketing funnels, etc.

That’s just hilarious. As someone who runs a business, I wouldn’t spend a single minute of engineering resources on anything that we don’t sell directly to a customer.

I’d go even further and say if you have less than 5000 employees, ALWAYS buy. Never build.

If you're an engineer in a larger software organization, you probably don't have that spending authority. Which means you have to spend time convincing the people with that authority to spend that money.

That's enough of a friction point that many engineers won't bother - which is why I talk about the invisible cultural damage that this problem causes.

You and I know that it will be cheaper. The challenge is getting organizational buy-in.

However, at the end, a somewhat more sensible advice is presented:

> I suggest that you prioritize buying to building, unless building will provide a real sustainable advantage for the business.

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.

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.

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.

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.

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.

The only thing I can really offer you is that in the spirit of this article, when I did some work that would run on AWS lambda it was very handy not to have to think about any of the infrastructure that was around the business logic I needed to code.

I fully expect that code will spend its entire useful lifetime running in AWS Lambda with no need for it to escape the vendor or technology behind it. It's even possible no one will think about it until it breaks and stops sending events.

If it costs the company £50/hour for me to look into something, me being able to complete a task quickly and then never look into it again is almost certainly going to save more money than writing a dedicated process and running it on a physical server that I then need to maintain.

The amount of bureaucracy at large companies cannot be overstated, especially when technology is a cost or auxiliary to the core business.

I’ve run into this twice in my 24 year (!! good god, am I that old??) career.

The worst was during a several month consulting gig for an investment bank, and it was extremely painful.

Every change to the dev and uat environments required sign-off and approval, from sys admins who were in a different timezone.

If the changes had cost implications, it would have been far worse.