For many organisations, the decision to buy software vs building it rests primarily on cost and time to market. However, a great deal more should be considered when making the decision.  

This is according to Deon Thomas, Managing Director of eBlocks Software, a software engineering specialist focusing on data, AI, DevSecOps, cloud and platform modernisation.

Thomas emphasizes that building or buying software isn’t purely a procurement decision - it is a strategic one that could help organisations differentiate from competitors in the market, or hold them back.

“We see the build vs buy question a lot among local organisations. Our view is that it's not a binary question of cost alone. Instead, our approach is that they should look at it as a strategic decision around capability and differentiation,” he says.

‍

Before you buy

Buying software typically accelerates immediate outcomes, but there is a risk of over-reliance on a vendor that can limit agility, Thomas says.

“Buying delivers speed, scalability and the benefit of a proven platform. You may also have advantages like vendor support to innovate and customise the solution. However, the trade-off is user-to-vendor lock-in, limited customisation, and most importantly, you run the risk of aligning your roadmap with someone else's priority,” he says. “When the market or your business model shifts, you may need a specific feature, but it’s not on the vendor’s top priority at the moment, so you can't innovate and you can't differentiate.”  

When you buy software, you may also be getting a lot of features that you don't need, and pay a premium for them, he adds.

“We typically encourage clients to think in a loop when buying: scheduling re-evaluations every 12 or 18 months to ask whether they are still getting value continuously, whether the market has evolved, and whether they are now in a position to internalise some of the capabilities.”

‍

Building differentiation

When building software, organisations can develop specifically what they need, without paying for features they don’t.

“Building will give you control, flexibility and the opportunity to create something unique that is fully aligned with your business model. It can become a true differentiator if it drives competitive advantage,” Thomas says. “The downside of it is the investment - not just in money terms, but over time. Organisations must consider how much they have, whether they have the talent to support it, and the implications of maintenance.”

He warns: “Building can be likened to adopting a child. It's a long-term commitment. You own the evolution and the depth and opportunity, and if it is managed well, it becomes a strategic asset. But if it’s not managed well, it can drain core capabilities from your business.”

Seeking differentiators

“For us, the decision on whether to build or buy should hinge on what differentiating capabilities you’re going to get, and which capabilities deserve ownership. We always advise customers to build what differentiates them and to buy what standardises them,” Thomas says.

He cites the example of a standard mapping recruitment process. “A recruitment process typically is going to stay quite standard. You need to source candidates, interview them and perhaps comment on some of them, so you need to have a management system and a tracking system. These basic features won’t offer you differentiation in the market, so buying the software makes sense,” he says. “However, if you can achieve differentiation by using AI to identify the top candidates and to identify the skill level in depth of a candidate based on their work history and their education, you could decide to build that portion yourself.”

He adds: “For us, it’s about quantifying strategic value - it's never just about the cost that we're trying to save. Ultimately, ROI in build vs buy isn't limited to licensing or engineering hours or the time that we're going to give them. It includes agility, risk, and opportunity. We help clients create total cost of ownership models that can account for the licensing, implementation, integration and updates, exit strategies, strategic obsolescence, and planning for change before it happens.”

“We stress small POCs, or testing before you commit, with controlled pilots to reveal how a product actually performs in the real business environment.”  

“When the ROI is assessed through both an economic and strategic lens, the decision becomes far clearer and far more defensible at a board level,” he concludes.

To help organisations weigh up the pros and cons of building vs buying, Eblocks has published a white paper outlining a framework for evaluating, acquiring and evolving software capabilities. To download the White Paper, click here

‍