As market demands accelerate, tech leaders across industries are navigating the trade-offs between the speed of buying and the control of building software

When it comes to the build vs buy debate, most technology leaders find themselves making less of a philosophical choice – instead, navigating around a daily friction point.

Traditionally, businesses could buy commodity software to save time or build proprietary systems to gain control. However, as enterprise architectures become more complex and AI accelerates development capabilities, the decision-making process – and focus – has shifted.

The reality is that very few enterprises are purely building or buying. Instead, they are managing a sprawling portfolio where the two approaches constantly overlap. This means that the challenge is no longer just selecting a vendor or hiring a development team – it is determining exactly where a company’s competitive advantage lies and applying the right resource to it.

Historically, the buy argument relied on the promise of it being the ‘easy button’. This meant that SaaS vendors could pitch the dream of instant implementation: swipe the corporate card, onboard the users and solve the business problem. But experienced CIOs know that plug-and-play is rarely that simple in an enterprise environment.

It is not all win-win, though. Buying software today has the tendency to build a different kind of debt: integration debt. As organisations stack dozens, sometimes hundreds, of disparate SaaS tools, data has a habit of becoming siloed and workflows appear fragmented. This means the labour saved on coding is often displaced onto engineering teams which end up building APIs to make these so-called easy solutions talk to one another.

The modern strategy is one that requires a realisation that you are never just buying a tool, you are buying into a vendor’s roadmap, update cycle and definition of how your business should work.

Does this mean the ‘build’ option is on the up? This used to be a method synonymous with risk thanks to the threat of bloated budgets and missed deadlines. But, with Gen AI now widely adopted across this area, it – along with low-code platforms – is fundamentally altering the economics of custom development.

With AI coding assistants capable of generating boilerplate code and testing scripts in seconds, the barrier to entry for building proprietary tools is significantly lower than it used to be.

It means that internal teams can now spin up microservices or custom interfaces in weeks rather than months. There is a catch, though – this speed brings a new danger: being just because you can build it, does not mean you should.

The maintenance burden of custom code remains and, without strict governance, shadow IT can explode, leaving an organisation with a patchwork of unmaintainable applications.

This leads to the ultimate question: how does one choose?

The AWS approach

For Ishit Vachhrajani, Global Head of Technology, AI, Analytics and Executive in Residence at AWS, the ‘buy first’ mentality is a relic of the dot-com bust – a conservative reflex that no longer fits the cloud era.

He argues that, while buying commodity software makes sense for standard functions, the assumption that buying is always faster is often flawed due to bureaucratic drag.

“We often overlook months and sometimes years spent in requirement gathering, vendor assessments, gap analysis, demos, scorecards, negotiations and procurement,” Ishit says.

With the view that the cloud has fundamentally flipped the build vs buy equation, Ishit argues that, while buying is often sold as the fast option, the reality of vendor assessments and procurement often drags on for months.

The AWS alternative is instant agility. For Ishit, AWS Serverless and Lambda have the power to bypass bureaucratic gridlock.

“For example, our team at A+E migrated off a third-party, off-the-shelf reporting product by building a solution using cloud native services from database to application layer that ended up reducing our cost from several thousand a month to US$5 per day while enhancing customer experience,” he says.

Pushing for Salesforce

Salesforce provides a compelling argument against building from scratch. Operating as customer zero, the company deploys its own commercial products internally, proving that using an established platform outpaces custom engineering.

Its CIO Juan Perez exemplifies this. Joining the cloud-based software company after 30 years at UPS, he argues that the most effective strategy for a modern enterprise is to resist the urge to build ad-hoc solutions and instead “push for the Salesforce platform”, as he told Boldstart.

From where he sits, the alternative – building custom fixes “any way we can”  – leads to a sprawl of disconnected data repositories and technical debt. “What I’ve come to learn is that every company has its own sets of data issues… because of the speed that business is moving,” he says.

By using Salesforce’s own Data Cloud and AI products to run the business, Juan’s approach forces his IT team to have a “direct line of engagement” with product developers, ensuring that the software is battle-tested. By prioritising the platform over custom builds, Juan ensures that Salesforce does not just sell the future of IT – it lives it.

The SAP alternative

Muhammad Alam, Member of the Executive Board of SAP and lead of the Product & Engineering Board, says the build vs buy debate often ignores the hidden cost of fragmentation. He argued at SAP Sapphire that years of ad-hoc technology adoption have left many enterprises with a “disparate and heterogeneous application landscape” that stifles innovation.

“We estimate that organisations can spend up to 80% of their effort and budget putting together this fragile balance of apps and data, leaving only 20% of your resources to focus on value creation,” he says.

The SAP alternative is to stop building connections and start leveraging what Muhammad calls a unified “flywheel of apps, data and AI”. By adopting SAP’s Business AI approach – anchored by the omnipresent copilot Joule – companies can skip the integration headaches. Instead of building custom AI agents from scratch, they can deploy SAP’s library of agents or use the new AI Foundation to extend capabilities safely.

For Muhammad, that true differentiation comes from “end-to-end context” and not complexity: “This can only happen when you simplify and innovate your core and not add another layer of complexity to your landscape.”