gshc2020.com

McKinsey’s latest data shows 32% of organizations decided against off-the-shelf software and built their own using AI. This dynamic sent SaaS stocks plummeting earlier this year, but many have regained some ground (registration required) as reality sets in.

However, it can be technically hard, time-consuming and even more expensive long term to build software than to buy it from a specialized vendor. MIT Research last year found that “external partnerships with learning-capable, customized tools” reached deployment 67% of the time, compared to 33% for internally built tools.​

I recently came face to face with the buy-versus-build decision myself. We needed a data-labeling tool, and a team set out to build it internally. As soon as I found out, I killed the project. It didn’t make business sense to move the intellectual horsepower of our R&D off what brings our customers value, just to potentially save on tech spend.​

Pressure To Go With AI​

What worries me about the uptick in build decisions is that many leaders are still blindly trusting AI. My company, SmartBear, recently surveyed 1,436 technology professionals whose organizations use AI in development. The research found that 73% of tech leaders say they have a lot or complete confidence that AI-generated code behaves as intended, compared with 52% of practitioners. ​

It’s this overconfidence in AI that can lead companies to build when they should buy.​

The best leaders, however, will weigh all aspects of the build-versus-buy decision, including potential impact on application integrity, meaning whether software works as it is supposed to, and risk to mission-critical applications.​

I see a clear instance where internal, custom builds may make sense. If you’re paying a lot of money for a tool that isn’t tied to mission-critical work, and you only need a subset of the capabilities of the tool, it can be a candidate to build internally. ​

You will, however, need to have the technical skill to build it yourself in a way that’s maintainable and accurate. This is not easy, although AI may make it seem so. Very rarely will you ask Claude or Codex to do something and have it respond, “I cannot.” ​

Questions To Consider​

If the buy-versus-build calculation is not as clear-cut as those examples, here is my list of considerations to inform decision-making: ​

Is the application mission-critical?

If so, homegrown is way riskier. The cost of a homegrown tool, including an error that escapes into production, say on a manufacturing line or in a financial services security breach, is huge.

Mission-critical is in a class all its own when it comes to application integrity. On systems like these, a vendor that specializes in that use case is the safer bet. For non-mission-critical applications where the cost of error is low, that risk calculus flips: A well-tested homegrown build can be the sensible move.​​

Does the software require audit, compliance, other governance oversight or continuing support?

If so, the total cost of a homegrown build adds up. Even if the original build feels compelling and doable, O’Reilly analysis found that maintenance costs account for 60% of software ownership over its lifetime​. Automation and AI tools may reduce that, but it’ll remain a big chunk of spend.

Any application with strong governance and audit requirements will likely require long-term maintenance. Needs can change often, even daily, and teams need to be on top of them or risk missing important requirements. A vendor that lives and breathes those requirements can often absorb that churn more efficiently than a team maintaining it as a side project. ​

What is my budget, and is it wisely allocated?

Given excitement over AI, there can be a commitment to spend on AI. That may make it easier to use AI to build software than to secure funding to buy software.

Don’t let this dynamic drive a short-term decision that impacts budgets and operations for years. The key is weighing the full lifetime cost of a build against the cost of buying, not just the upfront price tag.​

How good is the AI at building what you want?

If it operates at the edge of its capabilities, that’s a big downside. Harnesses like Claude Code and Cursor are great at exploiting large language model (LLM) capabilities for a specific task, like coding, for instance. But if they’re over-extended into use cases outside of that domain, their capabilities decay, in my experience.

Knowing what problems you should use AI to solve rather than assuming it can solve all problems will remain a key leadership skill.

What are the integration challenges?

Enterprises have complex software systems that tools need to integrate into, along with their own proprietary data sets. Factor in the integration costs and challenges, and whether you have the capability to integrate something yourself.

Major integrations are often delivered out of the box, and maintained, by vendors as part of the SaaS fee.​

What is the security risk?

If you accidentally build malware into your homegrown tool, what’s the cost to operations, brand and customer relationships? That wouldn’t be anything I’d want to explain to an impacted customer.​

Be Rigorous ​

All in all, senior tech leaders and engineers need to be clear-eyed on the tasks that AI tools are well-suited for and those that they are not.

AI can make internal builds easier in some cases. But what’s built has to work, all the time, perhaps for a long time. Overconfidence in AI on the build versus buy consideration can, and will, come back to haunt you.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?