Two decades of enterprise technology produced one durable lesson: build what gives you competitive advantage, buy everything else. That lesson was right when Salesforce demonstrated in 2003 that CRM did not need to be built; it needed to be subscribed to. It was right when the Modern Data Stack pushed analytics infrastructure into the buy column. Each wave reinforced the same logic: let the vendor manage the commodity and direct energy toward the business problem.
The AI era does not overturn that lesson. Applying it correctly, though, requires answering a prior question: what actually constitutes competitive advantage now? That answer has changed.
The data makes the case first
MIT's 2025 GenAI research found external partnerships reach production at roughly twice the rate of internal builds. The finding is counterintuitive only if you have been watching enterprise AI announcements rather than outcomes. The announcements favour building: proprietary models, bespoke pipelines, custom agents. The outcomes favour something much closer to what the SaaS era already taught organisations to do. S&P Global puts the cost of the default-build instinct in starker terms: 42% of companies abandoned most of their AI initiatives in 2025, up from 17% in 2024, and the average organisation scrapped 46% of its proofs of concept.
The build instinct is being applied by default rather than by design. In a fast-moving field, that default carries disproportionate cost.
Why building is a harder bet now
Four forces are simultaneously working against the build case in a way that has not been true before.
Commoditisation is accelerating faster than most build timelines. A capability that justified a proprietary build decision in 2023 is now a standard feature in most enterprise platforms. Coding copilots and RAG chatbots were build-worthy decisions two years ago; by 2025, both are default buy. The cycle from differentiated capability to commoditised platform feature is running at approximately 12 to 18 months, driven by genuine scientific discovery, not just engineering iteration.
Established platforms are compounding their AI investment at a scale most organisations cannot match. The major cloud providers, data platforms, and enterprise software vendors are directing tens of billions of dollars annually toward AI features. Building a proprietary alternative is a bet your internal team will outperform that collective investment. It is rarely a neutral choice.
The expertise gap is widening faster than internal teams can close it. Organisations building AI in-house work on one organisation's problems. Vendors, consultancies, and specialist partners doing this work across dozens of organisations accumulate applied learning at a rate internal teams cannot replicate: the evaluation framework that held together in testing and unravelled at scale, the agent workflow that performed well in a pilot and produced confident wrong output in production. Internal teams encounter these failure modes for the first time, on their organisation's timeline.
Building concentrates risk at the worst possible moment. Proprietary AI implementations put execution responsibility on internal teams at a time when failure modes are still being discovered across the industry. Buying and partnering distribute that risk across a vendor's entire client base; when an internal build fails, that cost sits entirely with your organisation.
None of these forces is individually new. What has changed is that all four are true simultaneously, and the pace of change makes each one sharper.
Why "always buy" is the wrong conclusion
The data and the four forces above could be read as a case for buying everything. That conclusion is as flawed as reflexive building.
Some capabilities are specific to your organisation and genuinely cannot be purchased.
Consider what "high-value customer" actually means in your context. Not the formula: the definition. Does a member who earns entirely through a partner channel but never directly engages count? What about someone who spent heavily for two years, lapsed for 18 months, and just returned? Your organisation has argued and resolved these questions. That resolution encodes years of strategic debate about loyalty, channel economics, and what growth actually means for your specific business model. An AI agent operating on a generic definition will misclassify thousands of customers and recommend the wrong interventions with complete confidence and no indication that something is wrong.
The same applies to anomaly classification: whether a 12% revenue drop is a bank holiday, a pipeline delay, or a genuine business problem depends entirely on context that analysts carry implicitly and agents do not.
These capabilities do not exist in a vendor's catalogue because they are yours. They compound every time your organisation uses them. A better model is available to every competitor; the context that makes a model useful in your specific environment is not.
Models are engines. What makes them useful is everything surrounding them: the definitions, the business rules, the evaluation frameworks, the domain context. In the SaaS era, that surrounding layer was connective tissue, the integration work that held the stack together but generated no competitive value. In the AI era, that layer is where intelligence is encoded. What surrounds the model determines whether the output is useful or dangerously wrong, stated with confidence, at scale.
Orient before you classify
Four questions should be answered before any capability gets classified.
What capabilities do you need to win? Not what vendors are currently offering. What capabilities, if your organisation had them and competitors did not, would compound into durable advantage over three to five years? Name those before any procurement conversation begins.
What do you already own that compounds? Most organisations undercount this. Business logic encoded in existing models. Customer understanding held in analyst judgment. Metric definitions embedded in documentation nobody has reviewed in two years. Naming these assets prevents purchasing tools that duplicate or displace institutional knowledge already in the building.
What are competitors building that cannot be bought? If a competitor's advantage is available as a vendor product, buy it and direct energy elsewhere. If it is not available to purchase, that absence is the build mandate.
What specific advantage do you bring here that a vendor cannot replicate? Proprietary data no vendor can access, earned domain context no product can encode, and the internal capacity to build and sustain better than you could buy are all legitimate grounds for ownership. If none of these apply, the build case rests on preference rather than advantage. This question is the filter that separates genuine strategic differentiation from the default build instinct.
All four questions orient every classification that follows.
The Capability Ownership Framework: buy, rent, or build
Once oriented, every capability can be classified into one of three categories.
Buy what depreciates
Infrastructure. Foundation models. Coding assistants. Off-the-shelf AI features. Commodity interfaces. Generic natural language layers on existing BI tools. These capabilities are simultaneously improving and falling in cost. Owning them creates no durable advantage; accessing them does.
Every buy decision should be documented with the rationale. Undocumented buy decisions accumulate into portfolios of hundreds of applications that nobody can account for, consuming integration capacity and organisational attention that belongs elsewhere.
Diagnostic: will this be widely available and cheaper in three years? If yes, buy it.
Rent what accelerates, with discipline
Transformation programmes. Specialist AI implementation. Large integration projects. Capabilities that are valuable for a defined period, delivered through external expertise.
This category requires discipline because expertise in a rapidly moving field has a short half-life. Partnering makes sense precisely because the field is changing faster than most internal teams can absorb; it does not make sense as a permanent substitute for building internal capability.
Every rent engagement sits on one of two paths. The first is episodic: access expertise for a defined period, then stop. A consultancy providing strategic clarity before capital is committed fits here; the engagement ends and no ongoing capability is required.
The second path is a staged transition to ownership. A specialist partner helping build evaluation logic or encode business definitions is a rent arrangement, but the output must be organisational intelligence that remains when the partner leaves. This requires explicit knowledge transfer written into the contract, internal team members learning throughout, and exit conditions defined before the work begins.
If neither condition applies, the organisation is building dependency rather than capability. If this partner exits tomorrow, what do we own?
Diagnostic: will you be able to sustain this capability internally in three years if you want to? If the answer is no, and the output does not remain with you, restructure the engagement before committing.
Build what compounds
Semantic definitions and business logic. Evaluation frameworks for AI outputs. Domain context and institutional knowledge specific to your organisation. Proprietary decision workflows. These capabilities become more valuable every time they are used.
Access to better models is table stakes; every competitor has it. The ability to direct better models with superior organisational context is not. That is what separates AI that produces analysis an organisation can act on from AI that merely sounds right.
Every build capability needs a named owner, a metric that demonstrates growing value, and a home in a living Build Asset Registry. Without the registry, build commitments quietly become untracked dependencies, and the intelligence layer accumulates with whoever is currently implementing the tools rather than with the organisation.
Diagnostic: does this gain value every time your organisation specifically uses it, and can you sustain it internally? If both answers are yes, build it and own it permanently.
Getting there: the build progression
One principle applies above all others: validate first, always.
Every build capability moves through three phases in sequence.
Validate. Prove value before committing capital. Use prototypes, lightweight manual workflows, or available commercial tools to establish whether the use case delivers real value in your specific context. The exit condition is binary: commit to the next stage, or stop. An extended pilot that produces no decision signals the use case has not demonstrated value. Name the decision-maker who will call that outcome before the work begins. That single step prevents "continued piloting" from becoming the default answer.
Customise. Build the intelligence layer on the bought core: business definitions, evaluation logic, domain context. A rent engagement is often appropriate here, with a partner accelerating the build while the internal team learns throughout. The exit condition is internal independence: the team can maintain the capability without external support. If the partner exits and the capability degrades, this phase is not finished.
Own. Fully internalise the compounding asset. The capability deepens with every use and demonstrates measurable, growing value. The exit condition is a named metric that shows the asset increasing in value over time.
The staged approach matters because most build failures happen at the first step: organisations skip validation and commit engineering capital to a full build before proving the use case delivers value in their context. By the time the failure is visible, the sunk cost is large enough to extend rather than exit.
Governing the intelligence layer
The framework only holds if governance is treated as a design decision rather than an afterthought.
Three governance actions apply across all three categories.
Start a Build Asset Registry. Governed metric definitions, evaluation frameworks, and domain-specific agent workflows belong here. AI-assisted query generation and natural language interfaces on existing BI tools do not; those are buy. The registry keeps ownership clear as the portfolio evolves.
Name an owner for the intelligence layer. Without a named owner and defined scope, this layer will be handled informally and inconsistently, producing technically capable tooling that nobody trusts because nobody owns the definitions it runs on.
Assign a decision-maker before the first validate begins. The decision-maker has one job: call the binary outcome when the validate phase ends. This prevents the pilot trap.
The two AI failure modes
The distinction between the commodity layer and the intelligence layer was hard won during the Modern Data Stack era. It sits at the centre of this framework now.
Default build: organisations commit capital to proprietary models and custom agents before answering the orient questions, building capabilities that were never validated and never compounded. Default buy: organisations layer generic AI features onto business definitions that remain undocumented and ungoverned, getting output the technology produces correctly but the organisation cannot trust.
Both failure modes surface in analytics first. It is where AI-generated insights are challenged against business reality, where metric definitions are tested, and where confidence collides with context. Analytics leaders are often the first to recognise when an organisation has built capabilities that never mattered, or bought capabilities that were never grounded in its own intelligence.
Which failure mode does your organisation currently lean toward? If your AI investment is primarily directed at internal builds, yet you cannot identify what compounds with your organisation's use that no vendor can replicate, you are likely building before orienting. If your portfolio is dominated by vendor platforms and external partners, yet you cannot point to governed business definitions, evaluation frameworks, or organisational knowledge your organisation explicitly owns, you are likely buying before validating.
The tools will continue to improve for everyone. The intelligence layer improves only for the organisations that choose to own it.
Two decades of enterprise technology drove organisations to own less software. The AI era is asking them to own more organisational intelligence.
The principles in this framework will not change as models improve. What will change is the stakes. Every model improvement compounds the advantage of organisations that have built the intelligence layer, and compounds the disadvantage of those that have not. The tools will keep improving regardless of what any individual organisation does. The intelligence compounds only with deliberate effort.
If this was useful, Analytics in the AI Era goes deeper on questions like this every week. Analysis grounded in what is actually happening, applied to the work of leading data and analytics teams.
Subscribe here; free, and you can leave at any time.
If any of this connects to something you are working through, I would love to compare notes. Reach out.
