Should you build or buy your software? I touched on this subject during the Tech Pro Unicorn episode (#114), but had a lot more notes than could be covered - thus in this episode, I take a deeper dive.
Or listen at:
Published: Wed, 05 Jan 2022 16:39:59 GMT
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I'm going to look at the subject of build versus buy. Now, this was originally brought up in the last episode, which was actually in itself a reposting of an interview I did on the Tech Pro Unicorn podcast. During prep for that interview, I actually had much more notes than it was possible to cover in that interview. Thus, I wanted to take a bit of a deeper dive in this episode.
So let's start by framing the question, what are we talking about?
We're talking about software. Is it better to buy? Or is it better to build?
Traditionally, the rules have been quite simple - build what differentiates you, The thing that makes you different from your competitors - buy the rest.
In reality, it's much more of a Spectrum, and it's not always a clear cut answer. Yes, there are certain things that would make no sense to develop yourself - Word, Excel, many packages that you can buy that are standard packages - why build them from scratch?
But as in many things, it can be quite complicated exactly where on that spectrum between buy versus build is the right approach.
As I mentioned in the Tech Pro Unicorn podcast, and I want to be clear here, I do have a bias. I do bring a developer background to this conversation, thus, even if I try not to, there's almost certainly a level of bias I have towards development.
And I think that bias is actually quite an interesting consideration for you to have whenever you are considering this within your organisation. The team will have a bias probably built up through past experiences. So if your CEO has had a bad experience of building software, almost certainly he will have a bias towards buying it.
So the reason I raise this, firstly, so you know that I have a developer bias, but also to make us think about a bias when we're going through these decisions and make sure that we're not incorrectly making the wrong decision purely because of a bias.
Now, at a high level, the historic conversation has centred around risk, speed and cost - with often a bias towards buying.
Mark Schwartz in his book "A Seat at the Table", actually devotes an entire chapter devoted to addressing this bias.
Long term, listeners will recognise the name Mark Schwartz. He's the author of "War, Peace and IT", a book that I promoted heavily on this podcast before. It's aimed at the non-technical Executive on how to get the best out of it, thus very similar aims as my own. His almost companion book, "A Seat at the Table", is largely looking at the same subject, but it's written to the IT Executive. It's actually written to the IT professional looking to try and get to that CIO position, that "Seat at the table".
Mark talks about how these long held historic beliefs, this bias towards buy is now wrong.
He goes into quite some length over how he thinks about it when you are buying a product. Many people will believe when you're buying, you're buying something. He challenges this and actually says, no, what you're buying is the value of the effective benefit of what that future supplier will provide you.
So, for example, if the supplier goes out of business, the value is zero.
And this greatly changes the dynamics of buy.
You may think that you're buying a product, but you're not - you're buying services, you're buying a commitment from that supplier that that product will continue to work the way you want it to, continue to be supported, continue to be available. Ultimately, it talks about being a service transaction.
And when you compare that now to the change in economics brought around in terms of building your own software, the way that modern software development allows for orchestration of good libraries components the ability of things like cloud, it's now much easier and allows for a faster try and learn cycle. It allows you to try that minimum viable product adaption to do what the business really needs and to learn what the business needs.
He believes that supply of product relationship is a clumsy partnership in comparison to people working within your organisation, within your own teams, wanting to try to get the best for your organisation.
Let's take a step back. If you're thinking about building a software product versus buying a software product, let's think about those key factors. For me, and what I'm going to cover in the rest of this episode, the key factors are control, cost, time to market, agility, risk and asset.
Ok, let's start with control.
We've touched a bit on this one - I talked about Mark Schwartz's opinion, when you buy from a supplier, that software is in the hands of the supplier, they hold the control, you're buying that service rather than a specific product, you're buying into basically a supplier monopoly, especially if they're the people that actually build and provide that software.
If they have the only game in town to provide that one piece of software that you actually focus on, how much control are you likely to have? You're taking a huge amount of risk, which I repeat when we get back to the risk category. But you have to consider with that control being in the hands of the supplier, what happens, if any, future direction?
If you contrast that with build, that control is very much in your own hands, it's very much within the team that you have organised and created to build a product and to manage it on a long term basis.
Ok, let's move on to cost now.
Traditionally, when we've talked about buy, there's been an expectation that you're gaining economies of scale, that you're buying from somebody that's built it before. Thus, you're paying a fraction of what you'd have to pay to build it yourself.
It doesn't always work that way, unfortunately.
There is a real danger here that you're paying over the odds because you're actually buying much more than you would ever need. You're buying a product that's been built for many different use cases. And to be honest, you may not be using most of them. You may effectively be paying too much - for stuff that you will never, ever use.
It's not uncommon for suppliers to sell their products based on features. But when you truly look at those features, are they features that you're likely to ever need?
Yes, you could go and buy this wonderful product with millions and millions of features, but if you're only going to use two of them, that seems like an overspend. It seems like you're paying too much when you're only using two percent of that entire product.
You also have to consider the longer term cost of the product. Yes, you may be paying an upfront licence fee, or an upfront installation fee, but you have to think about the cost of the maintenance, the ongoing cost, the support costs - and your face them with the dangers of locking because of that control bias where you've got a supply monopoly.
Yes, you may have a contract in place for this year, next year, maybe three years out. But what happens on the fourth and the fifth? Can the supplier hike their prices? Are you left in a terrible position because you don't have options? Something you really need to think about, certainly before you make any long term commitments.
Lets also take into consideration the cost of you having to manage that product.
Its often sold as a "here by this product, start using it". But in reality, you probably need people to run it. You'll probably need them to help configure it, especially if it's quite a verbose and big product. You'll need people to spend time making sure it works for your organisation. You'll need people to help roll it out - to train, maintain and support.
There is sometimes a real danger here that you almost have as big of a team to support a bought product as is if you developed in-house.
You also find with these bought products, there's often gaps. There may be some gap between where you wanted to do this, and talk to this other system here. Now you may need to then invoke your own development costs to fill those gaps. As I talked about in the Tech Pro Unicorn podcast, I call this "glue code" where effectively you're developing things to glue systems together. So again, additional potential costs there.
The thing I want us to be clear on here is when you're buying a product, you're often talking in terms of a budgetary cost. Which often doesn't include everything that you need to take into account, so can be a poor illusion when you're trying to compare it to the cost of building it yourself.
So if you want to build it yourself, where's the cost there?
Now, for me, the big saving here is you build only what you need. You don't need to build the other 98% that you're not using in the product. You can make sure that you're actually focussed on the stuff that gives you value and using things like minimum viable product and experimental thinking, you can arrive quickly at what that gives you.
You may find when you sat down originally and looked at the product you wanted to buy, when you actually tried to build it, you actually find actually no, it was a wrong direction. But you only find that by learning and trying. Now, obviously, you're going to have to staff this, you're going to have to take into account the full lifetime of the product, interestingly, not much different than if you bought it. So you're going to need the developers to build it in the first place, but you also then need people for bug fixes, security.
You need to take that into account when you're weighing that cost up - which unfortunately means you do take a reliance on the market.
It can be difficult to get good software developers and retain them. You have to work at it as an organisation to make sure that you are attractive, to keep those good developers, to keep the teams to make sure they are working well. There is work there, there is an investment there.
And with you building it internally, it can be generally difficult to estimate a budget ahead of time. Many people try to budget for building exactly what you could buy. As I said, I think that's a fallacy because most of what you buy isn't what you're going to need. What you need is probably a very small subset of what you would buy. Plus, of course, it gives you the flexibility, and we talk about this when I get to agility, of being able to change direction much easier if you have the team in house to do it.
But there is always that danger of people getting caught up on the budget. I'm going to tell you now it's very difficult to arrive at a proper budget, sometimes even with buying, it's difficult to arrive at a budget because things change.
Much better in my mind, rather than trying to establish a budget and trying to force people to work to it, let the investment find its own ground. Invest in what you want to put in - invest an amount - see where it gets to.
If it's working great, continue to invest. If it's not working, look at it and understand why.
And in many ways, this comes back to why build can be an advantage in cost because you don't have to go and spend that massive great cheque up front. You don't have to commit to five years worth of licence fees in a buying situation. You can invest a trickle and build it as you go and get the benefits you want to.
Plus, when you've reached the level of benefit you think you need, you can stop investing more in it. It allows you to set the point where you reach the level of return on investment you think that's going to be the best that you can achieve.
Ok, let's move on to Time to Market.
Again, this is another reason people historically talk about buy. It's seen that if you buy a product off the shelf, it should be quicker, it should be easier to get that product into market - and they certainly can be true. I'm not going to dispute that. If you buy certain products, yes, you'll get them to market quicker than if you wrote them from scratch.
But it really depends on what that product is.
Sometimes these products are so big because they're trying to appeal to such a wide audience. There may need to be a lot of configuration, a lot of changes to make it work to exactly how your organisation works. So you end up actually spending a lot of time after you bought in the product, customising it - which arguably soon offset some of those benefits than if you went and built it.
I've certainly seen organisations taking on bought products only to spend multiple years customising it to how they want it to work for their organisation before they actually even got it into live.
This has to be something you have to be careful about and think about if you need to configure a product to how you work or you need to change your organisation to match how the software works - then you have to take that into consideration when you're considering that Time to Market.
Now, when you look at build, yes, often it's perceived as longer. And it can obviously depend where you are. If you're in a position where you have no development team, then standing up a development team and getting them into place can take a long time. I'm not talking weeks. I'm talking months, potentially 6 to 12, to get a good, solid team in place.
But once you have that, using that MVP approach may actually get you benefits quicker than even buying because you can use that experimental approach. You can get things into the market very quickly and get feedback from your customers.
Using the experimental minimum viable product mindset, you're in a position to try numerous small bets. You can experiment, you can have hypothesis and you can see which ones work - because the problem is you don't know until you really try it.
And by doing this, you may actually find the whole thing you're trying to embark on doesn't work. You may find the whole premise under which you're trying to do something is fundamentally flawed, which for me is possibly one of the biggest wins you can actually get from that MVP experimental approach.
Finding out that what you believed to be what the market wanted wasn't, and isn't something they'd want to buy, is really good to know quickly to reduce the amount of investment you waste. And that then gives you the opportunity to take the choice as to whether you continue to push into the market where you continue to invest, or if you continue to spend time trying to adapt your original hypothesis to find what works in the market, or you change tack completely and then find something else - another bet to invest in.
And so much about this is making sure you try to do it quickly - again, that Time to Market.
Let's talk about agility, that ability for you to change direction. Being able to change the product and the system so that it can take you where your business needs to go.
Now, if you're going to buy, you're very dependent on what the supplier provides you. Yes, there may be configuration options. Yes, they may have various bits that they can sell you. Yes, they may quote you to actually make further changes. But is that really going to get you where you need to quickly and adapt as you need to?
If you need to adapt and change direction rapidly, do you want to go for a big requirements gathering contract specs costing build exercise that is more traditional to the 12, 24, 48 month exercises that we've been used to in the past?
Now, often you can use things like the "glue code" technique to build things on the side of this product. But are you really getting the best from a product when you're having to then add extra bits to it? It's almost working against how the system was built originally.
One thing I would say, if you aren't buying, there's a good chance you're going to get good practises. You're going to get the sharing of ideas that that supplier has had with many of its customers. So there's a good chance that you'll get good things ready to use out of the bag, things you hadn't even thought about, things that may actually be beneficial for you because other people have found them useful. And sometimes this is the hidden gem of buying. And it would be wrong for me to hide that when you buy, potentially you're buying into a shared understanding of good practise.
Now, obviously, that really does mean that you're buying something that doesn't differentiate - you're buying something that is going to work, as many people have used, which if it doesn't differentiate you as a business, is a good thing.
Ok, let's talk about the agility from building. Obviously here, for me, this is all dependent on the investment and the imagination you have as an organisation.
You build what you need rather than buying what we don't - which I've talked about in both the control, the cost and the time to market. We still need to build the bits that we need, but by making sure that we can follow what is needed by the organisation, by using that minimum viable product, that experimental mindset, that feedback mechanism, we know that we can adapt quickly to the businesses needs. We know that we can go in the direction the business needs us to by virtue of the fact we're working in that adaptive, agile manner straight away.
Ok, let's move on to risk.
Often one of the arguments for actually buying is that it's believed to have lower risk. This I'd really question if I was honest, I think if you're going to buy, you are taking a reliance on that third party, you are taking a reliance on them being still there in 3 months, 6 months, 12 months, 5 years. You're taking a risk that their direction and their commitment to the product will continue to be where you want it to be.
You're also taking a risk on relying on them. When I talked about supply chain risks like the SolarWinds attacked a few episodes back, there's a danger here that you're taking a reliance on something that could cause you harm.
Now, I well understand that some people like the idea of having a third party purely for the idea of having a "neck to ring". Someone, that in the event of something breaking, they've got someone they can get on the phone and effectively shout at - not so easy when it's an internal team. Having a third party that you can blame, somebody you can go to and effectively shout at to resolve your problems can feel comforting to some people.
Personally, I think that's a very dysfunctional place to be. If you're looking to buy a product, purely say you've got a "neck to ring", that's a really strange place to be. That's a really strange way to enter any form of engagement. And one that I really wouldn't recommend.
So when it comes to the risk of us building products, I'd actually argue that modern software development reduces risk.
By using that MVP, quick, iterative development, we're taking small bets. We can adjust course as appropriate, versus buy when we'll likely be making a considerable investment for something that may not work as we need or expect it to.
Many of the problems that are touted with building, are also there in buying - not having the ability to get staff, worrying about security compliance, making sure that it's going to work appropriately. These are still concerns for buying, and you still need to make sure that their risks are covered, often by spending more money. So why would that make it any better than just going down the build path?
Now, there is obviously dangers in building. There's the loss of the development team, there's market pressures. And again, I talk about before about you need to make it an attractive place to work - using modern practise to make it easy to onboard new members, but even better to help you maintain a stable team.
If you haven't got a stable team and can't maintain a stable development team, the yes, go buy something - you're going to have no joy in trying to build it. If you cannot maintain a development team, you will struggle.
It needs to be a cohesive, well-thought-out team that's built to maintain and build the software. Otherwise, they will really struggle to build you anything useful.
But with that said, I still think the risk is in favour of build. You can learn quickly if your development team are actually working, if they're actually producing things as going to benefit the organisation. You can learn quickly whether or not they're heading the right direction, whether it's the development team, whether it's the hypothesis you had in the first place, whether it's the direction of flight you believe your customers want to go. By having that ability to experiment and iterate quickly, you reduce risk.
Let's move on to asset.
I'm talking about this basically if you build something - if you build something, you've got a possibly sellable asset, you have experienced knowledge experts in your team, whether it be the development team or your users.
Whereas if you buy, you've not really gained anything. It's like renting a house. You have the experiences of being in the house, in living in the house, but that's it. The supplier potentially has benefited from you providing additional input into how their product could be progressed, but you have nothing that you could sell. And in some cases, it actually becomes a negative - because you have those experienced knowledge experts in somebody else's product, their place on the market can become quite strong, with competitors wanting to use them so that they don't have to gain that experience themselves.
Now that we've covered those key factors, I wanted to spend a little bit of time talking about motivations, specifically the motivations of any sales person you're talking to when buying a product.
It worries me in this day and age that so many salespeople are commission led. They're commissioned for the sale. Many of them aren't actually engaged with you once you've signed the check. They're to get you in the door, then they're handed off to another team. They're not working with you for the long term.
So you have to question what is the salesperson in it for?
Are they just in it for the commission?
Are they worried about whether or not the outcomes of this software will work for you?
Or are they just telling you what you want to hear to get the purchase orders?
And I've seen this time and time again, when commissions and sales targets often drive dysfunctions, when salespeople oversell a product or even the wrong product just to get the purchase order in.
And even good supplies have different goals than you do. They're not there to deliver the goals of your organisation. They're there to deliver the goals of their own organisation.
In this episode, I've talked about buying software versus building software.
I've talked about some of the key factors you can consider, and I've challenged a number of them - and many of the traditional preconceptions about how buy is often better.
But unfortunately, there's likely not a perfect answer. As many consultants will always say "it depends". Now, as I said, right at the outset of this episode, I bias towards build, and I firmly believe it should be considered the default.
But I'm not naive enough to believe that build is always the answer. And unfortunately, it really does depend on your unique situation.
However, whichever way you go, whether it's buy or build, try to leave options available for later. As your organisation grows, it will likely become a blend of systems both built and bought working together. Ideally, you want to think hard about how these systems interact and how they could be replaced.
Having the options to swap out a buy to a build or vice versa provides options. It provides flexibility both as your organisation grows and you outgrow whatever product it is you're using now. Or you decide to the previous approach just wasn't good enough.
Having that ability and that flexibility to change again speaks to that ability to be agile and change as your business needs to in the modern world.
Thank you for taking the time to listen to this podcast. I looked forward to speaking to you again next week.