Should I build or buy software in the age of AI? (Scorecard included)

Something fundamental has shifted in software development. AI-assisted coding platforms have dramatically lowered the barrier to creating functional software. What once required a team of experienced developers, weeks of planning, and significant capital investment can now be prototyped by a single person in an afternoon.

A product manager can describe what they need and watch a working prototype materialize. The internal calculator that was never worth a development sprint can now just exist. Teams across every industry are racing to build internal tools with AI-assisted coding platforms. And rightfully so, every organization should be leaning into these capabilities.

But here’s the real question: just because you can build it, should you?

In this article, I’ll share how I evaluate that decision as both a CIO and a CPO, including the scoring model I use to determine when building makes sense, when buying is smarter, and when a hybrid approach is the right call. If you’ve felt the growing pressure to “just build it,” you’ll walk away with a practical framework to assess risk, cost, and long-term ownership before enthusiasm turns into technical debt.

What’s different now (and why it feels urgent in 2026)

Build vs. buy has been in the public discourse for years, or even decades if we look beyond AI-specific considerations, but the speed of modern builds has changed the decision psychology. In the past, building still required significant commitment from people, time, and money, so the build decision was naturally gated. 

Over the last 12 months, that gate has weakened. When you can build something meaningful in an afternoon, the default bias becomes, “Why wouldn’t we just build it?”

That’s why this question is being asked more than ever right now: it’s no longer hypothetical. Teams can actually do it. The temptation is real, the prototypes look real, and the internal momentum is real. 

The “chessboard” problem: my CIO brain vs. my product brain

I also have a unique (and sometimes conflicting) perspective on this decision because I wear two hats: CIO and CPO. Some days it really does feel like I’m playing chess with myself.

• As a product leader (CPO), it’s obvious to me why buying often wins: a focused vendor is learning from hundreds (or thousands) of organizations, iterating constantly, and building a depth of expertise you simply can’t replicate as a side project.
• As a CIO, I have to acknowledge what’s now possible and be honest about when building can be the right answer, especially for narrow, contained use cases and obvious process bottlenecks.

On the surface, it looks like a productivity revolution. But dig a little deeper, and I think we are looking at the early stages of an enormous collective waste. There is a crucial difference between creating software and owning software.

The 10/90 problem

In enterprise environments, building version one of a tool is often as little as 10-20 percent of the total lifecycle effort. The remaining 80-90 percent is maintenance, security patching, evolving requirements, integration upkeep, and the inevitable moment when the person who built it moves on, and nobody else understands how it works.

This is the part I keep coming back to when people tell me, “We can build that in a day.”

Yes, you probably can. I stand by that statement. You can build meaningful applications in an afternoon. But what hasn’t changed is that owning the application long term hasn’t gotten easier. Someone still has to deploy it, maintain it, and account for security and compliance, even if it’s “just internal.” AI hasn’t changed that equation yet.

When I experiment with building tools myself, the moment that forces clarity is not the first prototype. It’s the handoff question: What does this look like when I tell a team, “Go deploy this and own it”? Who owns it? What commitment are we actually making? That’s where I often take a step back and recognize the line between creating software and owning software.

AI compresses build time significantly more than it compresses operational accountability. It can help generate tests, draft documentation, and accelerate refactoring. But it does not remove the obligation to operate, secure, audit, and evolve the system.

The Redundancy Tax

At a macro level, thousands of organizations are independently developing their own versions of the same tools. Each one is paying separately to discover the same bugs, hit the same integration challenges, and patch the same security gaps. None of them benefits from what the others have learned.

I call this the Redundancy Tax: the aggregate cost of duplicated effort across an entire market that delivers zero competitive advantage to any individual organization.

The Redundancy Tax compounds across five hidden line items that most organizations fail to account for when making the initial build decision.

The economics are straightforward. This is the principle of specialization applied to software. You pay a specialist to solve a problem they have solved thousands of times, so you can focus your scarce talent on problems that are actually unique to your business. AI-assisted development has not changed this calculus. 

If a thousand other organizations have the same need, the world is better served by a single great solution than by a thousand mediocre ones.

The “40 to 50 internal apps” compounding effect

There’s another, more tactical way to see the redundancy tax: compounding internal app sprawl. 

Building one or two internal support tools is one thing. But if every department builds two or three, the CIO eventually inherits a portfolio of 40 to 50 internally built applications that now need to be maintained. At that point, the compounding effect becomes a distraction in itself.

Why teams build, and where it goes wrong

To be clear, teams build for legitimate reasons. They want to move fast, control the roadmap, keep data in-house, and avoid vendor lock-in. Those are valid motivations, and there are genuine cases where building is the right call. The mistake is treating prototype speed as evidence that ownership will be cheap.

I’ll add one more reason to build that has become more common in the AI era: teams run into a real requirement gap. They try a product, they can’t get it to do what they need, and the immediate reaction is, “Maybe we should just build it.” I’ve had that exact impulse myself.

But here’s the nuance I’ve learned: if the problem is complex enough that a specialized vendor building for hundreds or thousands of customers hasn’t solved it yet, there’s often a reason. If we attempt to solve it internally, we may simply be signing up for the same hard problem, but without the focus, domain depth, and compounded learning that a vendor gets from the market.

Governance didn’t get optional just because building got easier

One of the most underestimated failure modes of “just build it” is governance.

If we hand out licenses to AI-assisted coding platforms and fully decentralize building, yes, teams can move faster. But if we don’t know what problems these applications solve, what data they handle, how security and access control are implemented, and how the tool is deployed and monitored, we introduce massive risk, even for “internal” applications. 

Internal apps and internal access can still be a vector for compromise. Data handling is where this becomes concrete. 

If someone builds an HR tool that processes performance reviews, manager conversations, and other confidential information, you’ve just created a serious privacy and PII (Personally Identifiable Information) risk. Centralized governance still matters, not because IT wants to hoard control, but because the business has to manage security and compliance risk.

And this is where build vs. buy intersects with what I consider the defining challenge of the next few years: visibility. SaaS made it easy for anyone to sign up for subscriptions. Now, AI makes it easy for anyone to build systems. In both cases, the risk isn’t the price tag. Instead, the risk shifts to what the tool does, what it touches, and who has access to it.

A build vs. buy decision framework

The question is how to distinguish cases where building makes sense from those where it becomes a costly distraction. This framework assumes that at least one credible vendor alternative exists. If the category is immature or no product adequately addresses the need, a time-boxed build or open-source approach can be the right starting point.

The framework provides five dimensions, each scored from 1 (low risk) to 3 (high risk). The total determines whether you should build, buy, or pursue a hybrid approach. Here are the practical “pre-checks” I use when talking to teams:

• User scope: If it’s a large user base across the organization, it’s usually not a great candidate to build. If it’s a controlled user base for a narrow use case, it might be.
• Integration surface: The moment integration enters the picture, complexity rises — especially long-term maintenance — because now you’re dependent on other systems and release cadences.
• Data sensitivity: If the tool will handle sensitive information (e.g., PII or customer data), building typically implies a bigger investment than teams expect.

Timing: Ask these questions before building starts, because once you build, emotional attachment makes scoring less objective.

One important note on scoring: business-critical does not mean business-differentiating. Critical systems that are common across your industry, such as compliance workflows, payroll, or standard reporting, are among the strongest candidates for buying, not building.

And one hard gate worth applying regardless of the score: if the tool will require on-call support, regulated data handling, or enterprise-wide access controls and audit trails, the organization should assume it is funding a product team, not a project.

Why this framework matters more in 2026 and beyond

My strong belief is that we will have this conversation again next year, and my answers may evolve as the AI tooling evolves quickly. But the need for an objective framework won’t go away. The build surface is expanding faster than most organizations’ ability to govern it, and that mismatch is where cost and risk accumulate.

Build what matters

The organizations that will get this right are the ones that resist the urge to build everything just because they can. The best approach is usually composable: buy the platform for the 80–90 percent that is common, and build on top of it for the 10–20 percent that is genuinely yours.

Build what makes you unique. Buy what makes you efficient. And have the discipline to know the difference.

One last thing: “buy” doesn’t mean “don’t embrace the change”

I want to be explicit about something: the right response to AI-assisted development isn’t to clamp down. We should embrace technology and seek opportunities to streamline and optimize. There are plenty of suboptimal processes today. Teams still manage complex work in Google Sheets or Excel, relying on formulas no one else understands. Those are exactly the places where a small internal build can unlock real productivity without dragging you into a long-term ownership nightmare.

The key is the same key I keep returning to: explore options, but stay objective and prudent about when and where you build.