For CDOs, Chief AI Officers and CTOs, one of the most consequential AI decisions today sounds deceptively simple:
Should we build it ourselves or buy it?
A few years ago, the answer often came down to capabilities, cost and time. If a vendor could deliver something faster and cheaper than your internal development organization, you bought it. If the capability was sufficiently differentiated or specialized, you built it.
AI has scrambled that equation.
AI coding tools can now generate surprisingly sophisticated applications in days or weeks. Foundation models provide capabilities that would have required teams of data scientists just a few years ago. Cloud services, open-source frameworks, APIs and agent development platforms have made experimentation extraordinarily accessible.
Suddenly, the answer to "Can we build it?" is almost always yes.
And yet, enterprises appear to be buying more AI applications, not fewer.
Menlo Ventures' 2025 State of Generative AI in the Enterprise research found that 76% of enterprise AI use cases were purchased rather than built internally. Just one year earlier, the split was almost even: 53% purchased versus 47% built. Menlo also estimates enterprise generative AI spending reached $37 billion in 2025, more than triple the prior year.
Andreessen Horowitz found a similar pattern in its 2025 survey of 100 CIOs across 15 industries. Early in the generative AI cycle, enterprises frequently worked directly with foundation models and built applications themselves. As the application market matured, enterprises increasingly moved toward third-party products. One reason identified by the research is particularly telling: internally developed AI applications can be difficult to maintain and frequently don't create enough business advantage to justify that burden.
We have arrived at an interesting paradox:
It has never been easier to build software. But that may make it more important than ever to be disciplined about what you choose to build.
For the technology executives making those decisions, that requires thinking beyond the prototype.
Building V1 Has Never Been Easier
There is no question that AI has changed software development.
A small team can take an idea, use AI to generate code, connect it to a foundation model, add some enterprise data and create an impressive application remarkably quickly.
This is not merely theoretical. AI-assisted software development is already becoming mainstream. In a16z's CIO research, software development emerged as one of the strongest enterprise AI use cases. One technology company CTO interviewed for the research reported that nearly 90% of the company's code was being AI-generated through coding tools, compared with 10 to 15% a year earlier. That is clearly an edge case, but it illustrates how rapidly the economics of software creation are changing.
For a CTO or Chief AI Officer, this creates enormous opportunity.
Internal teams can experiment faster. Business units can test ideas that previously would never have survived the IT prioritization process. AI teams can create proofs of concept without requesting multimillion-dollar budgets.
That's good.
But it can also create a dangerous assumption:
Because the application was easy to build, it will be easy to own.
Those are very different realities to come to grips with.
The Demo Is Not the Application
Anyone who has spent time around enterprise AI over the past few years has probably experienced some version of this.
A team builds a compelling prototype.
An employee asks a question. The AI retrieves information, reasons across it and produces an impressive answer. Perhaps an agent takes an action. Executives see the demonstration and immediately start imagining what it could mean at enterprise scale.
Then someone asks:
"What would it take to put this into production?"
That's where the conversation changes.
The production application needs identity and access controls. Security. Governance. Monitoring. Evaluation. Auditability. Cost controls. Enterprise integrations. Scalability. Error handling. Model management. Testing. Documentation. Support.
Then come the harder questions.
- What happens when the underlying model changes?
- How do you know a new model version hasn't degraded a critical use case?
- Who monitors accuracy?
- How are permissions inherited from source systems?
- What happens when an upstream API changes?
- How do you evaluate multiple models?
- How do you prevent sensitive information from being exposed?
- Who supports the application at 2 a.m. when it has become embedded in a critical business process?
None of these questions makes the prototype less valuable. They simply expose the difference between building software and operating software.
AI has compressed the journey from zero to V1.
It hasn't eliminated the journey from V1 to V2 to V5 to V10.
Stop Comparing the Cost of Buying With the Cost of Building V1
This is where the traditional build-versus-buy calculation can become misleading.
A vendor proposes an enterprise AI application for $500,000 a year.
The internal team estimates that it can build something similar with four engineers in six months.
On paper, the internal option can look attractive.
But that's probably the wrong comparison.
The real calculation isn't:
Annual subscription cost vs. initial development cost.
It's:
Total vendor relationship cost vs. total lifecycle ownership cost.
The latter includes far more than salaries for the original developers.
It includes infrastructure, security, integrations, model and API consumption, monitoring, evaluation, testing, compliance, documentation, user support, enhancements, technical debt and ongoing engineering.
And then there is opportunity cost.
Every engineer maintaining an internal AI platform is an engineer who isn't building something else.
For CDOs and CTOs managing finite pools of data scientists, AI engineers, data engineers and architects, this may be the most important cost of all.
So perhaps the question for the investment committee shouldn't be:
"How much will it cost us to build this?"
It should be:
"Five years from now, do we actually want to own this codebase?"
AI Makes the Ownership Question Even Harder
Software has always required maintenance. AI adds another dimension because the underlying technology is moving extraordinarily quickly.
The model you select today may not be the model you want next year, or even next quarter.
The same applies to agent frameworks, retrieval techniques, evaluation approaches, orchestration technologies and model architectures.
a16z's CIO research illustrates just how quickly the model layer itself is diversifying. In 2025, 37% of respondents reported using five or more models, up from 29% the previous year. Enterprises are increasingly selecting different models based on performance, use case and economics rather than standardizing on one model.
That means the internal AI application isn't finished when it works.
Someone must continually determine whether it could work better.
- Could a new model improve accuracy?
- Could a smaller model reduce cost?
- Should certain workloads move to a reasoning model?
- Should another model handle coding, document processing or analytical tasks?
- Can we replace one model without breaking downstream applications?
A specialized AI software vendor has teams whose job is to answer those questions for its product.
If you build internally, you are that vendor.
That's not necessarily a problem.
But it should be a conscious decision.
The Strategic Question: What Should We Actually Own?
This brings us to what I believe is the more useful question for CDOs, Chief AI Officers and CTOs.
Not:
Can we build this?
But:
Should owning this capability create a competitive advantage for our company?
There are plenty of situations where the answer is yes.
A bank might develop proprietary fraud detection or risk models.
An insurer may build specialized underwriting intelligence.
A manufacturer might create AI that optimizes a production process unique to its operations.
A pharmaceutical company may develop AI around proprietary research.
A retailer may build sophisticated pricing or recommendation capabilities that materially affect customer experience and margin.
In these cases, the technology itself, or the way it combines proprietary data, expertise and algorithms, can become part of the company's competitive advantage.
Building can make perfect sense.
But consider the opposite category.
Should the same manufacturer build its own enterprise search platform?
Should the bank build a generic coding assistant?
Should the retailer create its own identity system?
Should every company build its own AI orchestration, governance, natural-language analytics or agent infrastructure?
Maybe.
But there should be a stronger reason than "our developers can build it."
The ability to build something is not evidence that building it is strategically valuable.
Build vs. Buy May Be the Wrong Choice
MIT researchers have proposed a more useful framework: buy, boost or build.
Buying provides faster adoption and shifts much of the development and maintenance burden to a vendor.
Building provides maximum control and differentiation but requires the organization to assume responsibility for developing, operating and maintaining the solution.
The interesting middle ground is what MIT calls boost: take an existing AI capability and enhance it using proprietary enterprise data and context.
This third option deserves more attention.
Because for many organizations, the competitive advantage isn't going to come from owning another AI application.
It comes from what they know.
- Their data.
- Their business processes.
- Their customer relationships.
- Their domain expertise.
- Their intellectual property.
- Their business rules.
- Their accumulated institutional knowledge.
Those are assets no foundation-model provider or software vendor inherently possesses.
That suggests a different enterprise AI strategy:
Own what makes your business unique. Buy the infrastructure that helps you exploit it.
Your Competitive Moat Probably Isn't the LLM
This becomes particularly important as foundational AI capabilities become broadly available.
Most enterprises can access the same leading models.
They can hire people with similar skills.
They can use the same open-source frameworks.
And increasingly, they can use AI itself to generate the software required to assemble those components.
So what remains genuinely proprietary?
Your business context.
Consider a seemingly straightforward question:
"Which customers are most at risk of churn, and what should we do about them?"
The model isn't the competitive advantage.
Understanding what constitutes a customer, how churn is defined, which product relationships matter, what contractual rules apply, which behaviors indicate risk, how customer value is calculated and what interventions have historically worked, that is where the proprietary intelligence resides.
The same applies to supply chain, finance, manufacturing, healthcare, insurance or almost any other business domain.
AI democratizes access to intelligence.
It does not democratize access to your organization's knowledge.
That distinction should influence where technology leaders place their investment.
A Better Decision Framework for CDOs, CAIOs and CTOs
Before approving the next internal AI development project, leadership teams might benefit from asking five questions.
1. Does this capability materially differentiate our business?
If the answer is yes, building deserves serious consideration. If competitors could purchase an equivalent capability tomorrow without changing the competitive landscape, the strategic argument for building becomes weaker.
2. Where does the proprietary value actually reside?
Is it in the software itself, or in the data, processes, knowledge and expertise that the software uses?
If the differentiation resides primarily in the latter, buying or boosting a platform may preserve the strategic advantage without requiring ownership of the entire technology stack.
3. Are we costing V1 or V10?
Don't compare a vendor's multi-year cost against a six-month development estimate. Model the people, infrastructure, security, evaluation, governance, support, upgrades and technical debt required over the expected lifecycle.
4. How quickly is the underlying technology changing?
The faster a technology category evolves, the greater the burden assumed by the organization that owns it. AI is currently about as fast-moving as technology gets.
5. Is this where our scarce technical talent should be spending its time?
This may be the most important question.
Your best AI engineers, architects and data scientists are finite resources. Every infrastructure capability they build and maintain carries an opportunity cost.
The objective isn't to minimize software spending.
It is to maximize the strategic return on technical talent.
From Chief Builder to Portfolio Architect
There's also a broader implication here for technology leadership.
For years, CIOs and CTOs have managed portfolios spanning packaged applications, cloud infrastructure, custom development and outsourced services. AI makes that portfolio more dynamic.
The Chief AI Officer and CDO increasingly have to decide not merely which AI projects deserve investment, but which layers of the AI stack the enterprise should actually own.
That requires architecture and portfolio thinking.
Some capabilities should be bought.
Some should be built.
Some should be assembled from multiple technologies.
And many will increasingly follow the middle path: buy a sophisticated AI capability and differentiate it with proprietary data, context and business knowledge.
The goal isn't maximum internal development.
Nor is it maximum outsourcing.
It is intentional ownership.
Applying This Approach to Enterprise Analytics
Over the past 20 years, the business intelligence market brought some great tools that have been adopted broadly across organizations. Think of the likes of Business Objects, Cognos, ThoughtSpot, Tableau and Power BI.
Most organizations pretty quickly determined that building their own BI platforms would not work. (I actually spoke to people in the early Business Objects days who were trying to build their own BI platforms.) The maintenance of that becomes too massive for any organization. Rebuild and test when Oracle releases a new version of their database. Microsoft releases a new version of their app server. Google releases a new version of Chrome.
The vendor took that burden away to a large extent. The job of the buyer was not trivial, but it was building on top of the BI platform. Each organization had to build their reports and dashboards in the tool. On its own, the tool is as dumb as a doorbell. And that in part was the ceiling placed on how far BI could go, because it requires technical people to construct those artifacts.
So, in a way, this is a pretty good model of the buy, boost, build paradigm. You buy the BI platform and boost it by building on top of it, adding your own reports and dashboards.
The advent of GenAI has opened up the same old notions of self-service, but the current crop of copilots is not bringing much success. The main issue is that these copilots are tool helpers, designed to reduce the technical difficulty of creating a chart, report or query.
In addition to the copilots, many organizations are building their own chatbots on top of their data lakes. The challenge everyone runs into is the lack of business context, resulting in AI hallucinating or providing inconsistent responses across your user community.
Back to our buy, boost, build model. You probably rightly want to build those chatbots and make use of the copilots. But in order to scale this, and not have to manually patch business context into every tool and custom app, you may need an abstraction layer between your data on one side and your consumption layers, the chatbots and copilots, on the other. That abstraction platform, which at Codd AI we call the contextual semantic layer, is where you boost with your own data, business knowledge, rules and logic. Changing a business rule is then done once and scales through every consumption layer.
If you want to go deeper on that specific decision for analytics, we covered it in more detail in Build vs. Buy for AI-Powered Analytics.
About Codd AI
At Codd AI, we believe enterprise AI should reason from a shared, trusted understanding of the business, not from isolated prompts or disconnected data sources. Our AI-powered contextual semantic layer combines technical metadata, business knowledge, governance, and human certification into a reusable enterprise foundation for conversational analytics, AI copilots, and agentic workflows.
By helping organizations capture and govern business context once, Codd AI enables every AI and BI application to deliver more consistent, explainable, and trusted insights, today and as the AI landscape continues to evolve. To learn more, visit www.codd.ai or schedule a conversation with one of our co-founders.