Buy vs Build is a lie, stop repeating it

Let’s be clear Buy vs Build is a fallacy, let's say Rent vs Build

We must refer to it as Rent vs Build. In most of the cases you or your company are not considering buying a technology or building a technology from scratch, you are considering renting an existing solution vs building one with existing components.

What’s renting

So when you go to a coffee shop and buy a coffee cup in exchange for money, you become the sole owner of that coffee. You decide if you want to drink it after a few minutes of your time, if you add sugar (I wouldn’t).

Most of the time in the world, you don’t buy software. I repeat, we DON’T buy software, we merely buy licences to use software. That was the commercial geniuses of Microsoft when they licensed their software to be used in IBM computers.

This action is more similar to renting: you are able to be there, ahem use their service, as long as you agree to the terms of conditions of the landlords.

When to rent

In some cases the discussion, should I rent or not depends on how strategic and commoditised is the capability or component you need. A strategic component is one that you need to control 100% of the roadmap because it’s key to the success of your company and you are the expert to get value from it. That’s why Zalando controls most of the software they build for their website, because it’s a critical component. Meanwhile renting servers is something more commoditised, that’s why most of us can go to one cloud provider and rent our servers or lambdas there. It’s standard, has comparable competitors and has clear SLAs. Simon Wardley would call them utilities in his Wardley Maps, the key performance indicator is efficiency. And it’s always renting, you are subject to their terms and conditions, and if you don’t follow them you can be evicted.

Another no-brainer example is for me email: you always need to send email, don’t need an email server, most of the time you’re better off with a third party email service unless there’s value your customer can perceive from having your own. Email has a standard protocol and known rules of how to operate, filter spam etc... You don’t need to host your own email server, or build your own email software because there are plenty of market services that can do for most cases.

When to build

You are better off building if the component is strategic and you need a lot of control on the roadmap. How it evolves, which features are added and which features are removed. You need to control how tightly coupled it becomes within your ecosystem and you can move faster if you do. Owning software is an asset that requires maintenance, high maintenance and it makes sense when it brings significant value that the customer appreciates, I mean they know they are paying for it and will keep paying for it. If your product is about improving a boring clerical process with AI, then those algorithms you use and the data sets are key components of your offering, you need to own them. How to operate these algorithms, using a processor or MLOps as a service is a good way to balance what you build vs what you rent, the servers that run the algorithms and the databases that keep your data.

When to replace 

It’s harder to let go of a system than not building it in the first place. When you start renting a service, you become entrenched in the service’s lock-in propositions, migration to other systems becomes more difficult, to the point you live with it, remember, when was the last time you changed databases for performance reasons?

On the other hand, some internal software you run will eventually fall behind with updates/maintenance and new feature development. You might even consider what to do, if it no longer fits your customers’ needs. You still have teams that worked in this system for months, years, that depending on the level of degradation will be eager to stop working with that code or look at it with melancholy of a golden past, when the system was better maintained. Your team needs to mourn their departure and picture themselves in the new landscape.