Buy vs Build: what’s the difference, and which is best?

We’re a couple of years into the AI rush right now, where organisations are tinkering with AI, its capabilities and trying to align outputs to some kind of business benefit. It’s not easy, is it? One challenge I’ve encountered within technology procurement for large organisations is a fresh take on the perennial buy vs build debate: which is better, which is worse, and how you should choose between them. As you’d expect, there is no right answer, but I thought I’d use my own experience to set out what they mean and the key differences between the two.

Let’s start by defining what each means. Build is about the internal development, delivery and maintenance of your own solution, providing funding for resources and infrastructure to deliver it, while buy means selecting or partnering a vendor to get access to their solution, usually by way of a monthly payment. Build typically – though not always – takes longer to achieve and can be cheaper in the long run, while Buy is the opposite, with shorter onboarding but a greater opex spend over time.

Build

Going the build route makes a lot of sense for many companies, because they can combine a tailored, bespoke solution utilising the native expertise of their teams. When trying to solve complex tasks in particular, keeping it all in-house should mean it’s right first-time and allows a greater, cheaper responsiveness to change.

I once worked for a large, UK-wide cash payments collection business and the combined complexity and short service level agreements (SLAs) with its clients meant that an in-house build was comfortably the best option. Indeed, an external audit while I worked there by a large consultancy confirmed that this was their best strategy, despite the cost of development, hardware and operational resources. We looked after the entire end-to-end system. It meant any outage, issue or error could be swept up quickly and fixed right away.

However, that won’t apply to all organisations. The level of automation in the set up, configuration and delivery of software tools today is extraordinary, meaning that with limited technical skills and budget, zero or low-code solutions are available with just a few clicks of a mouse. Microsoft have been doing this for decades. I recall stories about Microsoft’s Visual Basic development platform being using by estate agents (realtors) to build boutique solutions to run their practices. Even without full development teams available, you could quickly activate products to help operate your business.

There are other tertiary kinds of benefits, too: for example, investment in the research and development of new products can be tax efficient if the right evidence and scenario are presented.

The challenge with the build route is that delivery generally takes longer and requires more resources, including funding. The solutions delivered are also unlikely to ever be able to compete with market leaders either, so you’re either missing out on important capabilities or would need to invest more heavily to catch up.

Indeed, during my time as a software developer at company that produced intranet-based car sales platforms, each new client would bring a new request or idea that we developed on to our platform, so much so that, eventually, we had almost every base in the sales process covered. Whatever the business process or need, our platform could handle it with a few tweaks, and anything we developed would go back into our library for future use. For our clients to develop something to compete internally with what we had would have taken months, if not years, at huge expense and resource.

Buy

Procuring technology services is by far the fastest route to capability enablement. Even with a short trial or pilot, your business would be able to quickly observe and prove the benefits before going all-in. As mentioned, you can quickly access industry advantage if you buy from the best, and with so many cloud vendors offering so-called evergreen platforms, you’re always on the latest version to experience regular updates. AI is a perfect example; few would host an instance on their own tech stack.

There are advantages too with risk-outsourcing practices that might suit a company without much in the way of its own cloud infrastructure and data. It may be more suitable to export your SLAs, which I just mentioned as a Build advantage, to become the burden of an external partner. Crass as it sounds, you’d have a stick to beat them with if your service went down and could comfortably blame someone else (even allowing refunds if contractual terms allow).

However, there is the opex cost of SaaS-type solutions to consider. True, it would take several years of monthly payments to reach the development investment needed on the build route, but access to the solution is endless and you’re highly unlikely to be able to capitalise it as an asset either. Companies don’t like opex costs, generally-speaking, and it may be difficult to reduce or limit these in future without renegotiating a contract, usually at the expense of some capability or capacity. Worse, those costs may grow as your business does too.

Then there are the security and IPR hurdles. Some SaaS vendors will allow you to locate their solutions on your own cloud stack with the right access or, at the very least perhaps, provide APIs to ensure full interoperability. If your cloud platform has a suitably elastic payment structure that means you’re not losing out to buying another cloud service from someone else, then that might be okay, but shipping your data out to an organisation requires lots of additional controls and might be subject to legislation.

Also consider what might happen if the vendor goes bust. All your data, as well as the solution itself, might suddenly be inaccessible if this happens, quite apart from the operational risk it may present. This can be mitigated by hosting a third party solution yourself. I’ve worked on these before where in the contract with the vendor, there is a clause releasing all source code and data if the vendor’s business is wound up to allow continuity.

The intellectual property challenge is an interesting one. If your business’ IPR is tied up in its data or processes, such as in civil engineering for example, then buying in a solution might not be palatable. If the opposite applies here, then it would of course make more sense.

Conclusion

The most vital element of this debate is around timing. Think about your objectives and use this to determine as early as possible where your solution needs to sit. It would be hard to row back from a trial with a SaaS provider when you subsequently decide that the costs are too prohibitive, or their cloud stack doesn’t match yours.

This is also where the innovation process comes in; deliver a trial, perhaps more on the buy side than build, to prove the business need and any benefits first. Then you have a better understanding of the solution needed and which route is right for you.