Buy versus Build

The buy versus build debate is one of the constants in the tech industry. Should you get a product off the (virtual) shelf, or invest in developing something bespoke to your needs?

I was recently asked my views on the question, and thought it worthwhile to note where my head is currently at on the debate.

The starting point for buy versus build is, I think, a question of scale and value. Buying a machine (which is essentially what you do when you invest in software) needs to be an exercise in purchasing scale of some sort. There is still a train of thought that exists that suggests that using software immediately purchases a cheaper way of doing things. That’s a little like suggesting that buying a car will make it cheaper to make journeys that you previously would walk.

What the car does is to allow you to either do those walking journies more quickly (don’t do that you lazy thing!), or to reach places that previously you couldn’t have got to (have you checked, though, whether you could get the train?). If you can get to places otherwise unreachable (scale) and those are places where for some reason you want to go (value) then it’s might be worth buying a car, assuming alternative methods are not available, not suitable or too expensive.

Let’s get back to software. And scale.

• Software can let you do completely new things. Things adjacent to your current business or maybe completely different. Scale through innovation.
• Software can let you do more of something. But software scale more is massively more, It’s usually 10x more (as our Silicon Valley friends are prone to say). Scale through amplification.
• Software can let you do more or the same of something with less resource. And usually that resource is people. Scale through efficiency.
• Software that you have bought can give you scale because the software product has been written for lots of customers, not just you. Scale through commercialisation.

In turn, let’s think about value.

• Software can give value to your business by driving up revenue, driving down costs, providing a better experience for your customers or your employees, and/or improving the governance and compliance of how you do certain regulated activities.
• Software can give value to your customers by providing a better, cheaper and/or faster service.
• Software can give value to your employees by making their working lives better. It can also have the opposite effect.

Many words, and we’ve not yet talked about buy versus build. But that’s important because if you don’t know “why” then how can you possibly address “how”? You’d be surprised how many people try, though…

If you can articulate the “what” you are looking to do, and the “why” you are trying to do it, then you can start to look at the current market to see if there are products or services that you might be able to find that meet your needs.

Need a spreadsheet or a word processor? Use Microsoft Office or LibreOffice or G Suite or one of the other many products in this space. Unless you want to launch a competitor product (and I’d suggest you probably don’t) these are known problems with known solutions and you would be foolhardy to try and build your own.

Do you need to run your finances or manage your employees? Again, there are a wealth of products in the market that will probably address your needs. They’re often a bit crap, if truth be told, but will you drive value in your organisation through a bespoke attempt to support these back-office functions?

When you get into “Line of Business” systems for a particular industry sector things start to get a bit more interesting. Many sectors have established software product markets to support the sorts of activities that all businesses in a sector have to operate. They are often archaic and exist because of the inertia that organisations feel when it comes to contemplating change. Vendors can get lazy – for example in my current sector there is a terrifying reliance on the long-retired Microsoft competitor to Flash, Silverlight for still in use housing systems.

Choosing to buy one of these antiquated systems over building one’s own might be a hard call to make – particularly if it’s seen by a commercial operation as a way of gaining a competitive advantage through doing things better. If you are in a non-competitive environment, the value proposition from uninspiring but solid Line of Business software may be stronger. Stronger still if the product has open interfaces so that you can build things around it, although keep in mind that the marketing sales tactic of “it’s got an API” is a bit like saying a Lego brick has nodules and so therefore you can build the Taj Mahal.

There is a newish breed of software product that is built on top of platforms like Salesforce or Microsoft Dynamics that I have seen in a few sectors. The product is a configuration of the platform tailored for a particular need or sector. The advantage here is that you have the scale of a massive Cloud platform, and also the companies providing the configuration have a need to keep their products up to date because the underlying platform is continually updating – “evergreen” in the software industry lingo.

This is the route that we have decided to take at RHP – a compromise between getting scale, being able to have a “good enough” set of software that meets enough of our needs, and a platform that holds the provider to account.

So, if there are products available in the market to do what you need to do, buy versus build is a question of value and scale.

If products don’t exist… well your choice is to build or to not build. If something doesn’t already exist to do what you want to do, you should take a long hard look at why nobody has addressed the need you have identified. Is it because it’s not a good idea?

If you think it is a good idea, then what sort of value might you drive? Keep in mind also that at this point building software is a lifelong commitment to spend money, not just a one-off investment. If the value you drive is half a day of administrative effort a week, but that’s to be offset with a day of developer time every week, well… Understanding the budget lines in which costs and benefits sit, especially when they are split, can be crucial here too.

So there we go. There is no one “right” answer. Everything is down to context. And the emergence of cloud platforms that themselves can be configured has changed the debate somewhat. Thoughts on this most welcomed!