Build vs. Buy in the Age of AI

When an organization needs a new software capability, one of the first questions is whether to build it internally or buy an existing solution.

Historically, the trade-off was relatively straightforward. Buying provided faster access to proven capabilities, at the cost of customization and control. Building offered greater control and a closer fit to the organization's needs, but required significantly more time, engineering effort, and expense.

AI-assisted development is changing that equation.

A capable developer can now create useful software in hours or days that might previously have required weeks or months. For many internal tools, the cost and time required to produce a working first version have fallen dramatically.

But this creates a new risk.

AI has compressed the cost of creating software much faster than it has compressed the cost of owning software.

A prototype may be inexpensive to build. A business-critical capability is not inexpensive to operate.

As people begin depending on a tool, the obligations surrounding it change: reliability, security, integration, observability, support, change control, recovery, compliance, and organizational accountability all begin to matter.

The same software can therefore become substantially more expensive without gaining a single new feature.

What changed was not necessarily the code.

What changed was the organization's dependency on it.

That distinction should now sit at the centre of any build-vs.-buy decision.

Before Build vs. Buy: Does the Capability Already Exist?

Before evaluating whether to build or buy something new, ask a more basic question:

Does this capability already exist somewhere inside the organization as an unsanctioned tool?

Increasingly, the answer will be yes.

It may be a spreadsheet, an Access database, a collection of scripts, a lightweight internal application, or an AI-generated tool created by an employee to solve an immediate problem.

If people already depend on it, the decision is no longer simply build versus buy.

It is:

Legitimize, replace, or retire?

That is a different evaluation.

The people currently using the tool need to be part of the process because they hold institutional knowledge about the real requirements. A procurement team evaluating a replacement in isolation may understand the stated requirements while completely missing the behaviours and workflows that have made the shadow tool valuable.

The existence of a shadow tool also tells you something important: there is probably enough unmet need for someone to have already acted.

Before selecting a solution, determine whether the capability is primarily a commodity or a differentiator.

Commodity Capabilities

Commodity capabilities are necessary to operate the business but generally do not distinguish the organization competitively.

Payroll, payment processing, identity management, expense management, and many other packaged business capabilities fall into this category.

For commodities, the affirmative case for buying is often stronger than simply "it's cheaper."

Vendors in established capability areas have concentrated years of engineering effort, domain knowledge, operational experience, security work, and customer feedback into solving a narrow problem repeatedly.

Their entire business may depend on getting that one thing right.

Buying therefore gives you access not only to software, but to compounded expertise that would otherwise have to be created and retained internally.

There is, however, an important trade-off.

Buying generally means accepting some portion of the vendor's definition of industry best practice. That can influence your processes and, in some cases, how you deliver value to customers.

Before accepting that compromise, ask two questions:

1. Does the product satisfy the critical use cases that matter most?
2. Are the important capabilities and data accessible through APIs so the solution can be extended or composed with other services where necessary?

If the answer to both is yes, buying a commodity capability is usually difficult to argue against.

Differentiator Capabilities

Differentiators are capabilities that contribute directly to how the organization competes.

These are the areas where custom development becomes easier to justify because the software may encode unique business models, processes, customer experiences, data advantages, or intellectual property.

A useful litmus test is:

Could this capability become distinctive enough that another organization might theoretically pay you for it?

If the answer is yes, that is a strong signal you are dealing with genuine differentiation.

If the answer is no, reconsider whether custom development is actually necessary. A thoughtfully composed set of commercial capabilities may reproduce most of the desired differentiation without requiring the organization to own an entire software product.

But even confirmed differentiators should not automatically be built.

Before deciding, there is another question to answer.

Traditional build-vs.-buy frameworks often treat "build" as a single category.

It is not.

There is an enormous difference between software built for one employee and software supporting a revenue-critical business process.

AI-assisted development makes that distinction much more important because it has dramatically lowered the threshold for creating the first version of a tool.

A useful prototype might now be created in a day.

But prototype speed is not the same thing as production readiness, and neither is the same thing as the ability to operate the software indefinitely.

Before evaluating build versus buy, ask:

Where does this capability sit today, and where is it realistically likely to graduate within the next 12–24 months?

That anticipated destination should determine how demanding the evaluation becomes.

Level 1 — Personal / Situational Utility

"If this breaks, I shrug."

This is where AI-assisted development thrives.

The tool may serve one person or a small trusted group. It exists to solve a local problem quickly. Manual fixes are acceptable. There may be little or no formal monitoring, documentation, recovery process, or infrastructure management.

Security may effectively mean controlling who has access.

That can be completely reasonable.

Applying enterprise engineering standards to every small internal utility would eliminate much of the productivity benefit that AI-assisted development provides.

Graduation signals

• Another person begins depending on it.
• Usage becomes routine.
• It becomes embedded in a workflow.
• Someone asks, "Can we rely on this?"

Those signals suggest the capability is moving to Level 2.

Level 2 — Shared Operational Tool

"If this breaks, someone Slacks me."

This is the first major threshold, and probably the easiest one to miss.

Multiple people now depend on the software.

When it fails, work stops.

At this point, expectations begin appearing whether anyone explicitly designed for them or not.

People expect predictable behaviour. Someone needs to understand failures. Data may need to be recoverable. Changes can no longer be made casually if they affect several users.

The capability begins requiring:

• basic logging;
• backups or recovery;
• predictable failure modes;
• documentation;
• clear ownership;
• a known support path.

None of these requirements may have existed when the tool was first created.

The code may barely have changed.

The obligation has.

Graduation signals

• Executive visibility appears.
• External stakeholders become involved.
• Important workflows become dependent on it.
• Someone says, "This can't go down."

That is a warning that the capability may be moving toward Level 3.

Level 3 — Business-Critical Capability

"If this breaks, we miss money, reputation, or commitments."

This is the danger zone for successful tools that began as quick builds.

The capability now carries meaningful organizational consequences.

Failure can affect revenue, customer experience, regulatory compliance, employees, suppliers, or contractual commitments.

At this point, reliability can no longer depend on the original developer being available.

The software needs a real operating model.

Typical expectations now include:

• observability across logs, metrics, and alerts;
• security controls and auditability;
• role-based access;
• controlled deployments;
• documented recovery procedures;
• explicit ownership;
• incident management;
• service expectations or SLAs;
• dependency management;
• test coverage;
• formal change control.

This is also the point at which informal ownership becomes particularly dangerous.

The developer who created a useful internal tool may suddenly find themselves operating a business-critical application without ever having agreed to that responsibility.

Ownership needs to become explicit.

Graduation signals

• Multiple teams depend on the capability.
• External customers or partners depend on it.
• Contractual guarantees emerge.
• Dedicated operational support becomes necessary.

At this point, the capability is approaching Level 4.

Level 4 — Platform / COTS-Equivalent

"If this breaks, we're on the hook."

At Level 4, the organization is effectively operating a software product.

The capability may serve large populations, support multiple domains, hold critical data, expose APIs, carry uptime commitments, or become foundational infrastructure for other systems.

At this point, the organization is either:

building and operating much of what a software vendor would normally provide, or

paying a software vendor to carry those responsibilities instead.

This is where the rationale for commercial software becomes particularly important.

COTS software does not earn its keep solely because it contains features you could not build.

Often, it earns its keep because another organization absorbs years of engineering, security, operational, compliance, legal, support, and organizational complexity on your behalf.

In other words:

you are not only purchasing functionality; you are transferring responsibility.

Once the capability type and likely gradient destination are understood, evaluate the options.

The criteria below should be assessed against where the capability is going, not merely where it sits today.

1. Strategic Alignment

Start with the basic question:

Is this capability fundamentally a commodity or a differentiator?

Differentiators create a stronger case for internal investment because they may encode unique organizational advantage.

Commodities create a stronger case for buying because there is little strategic value in recreating what a specialist vendor already does well.

AI makes one additional question necessary:

Has the economics of this capability changed enough that the old classification should be reconsidered?

Something that justified a substantial SaaS subscription five years ago may now be straightforward to build and maintain internally.

Conversely, something that appears inexpensive to build today may still be irrational to own once Level 3 or Level 4 obligations are considered.

Strategic alignment should therefore be reassessed periodically rather than treated as a permanent classification.

2. Cost

The cost comparison should be separated into at least three categories.

Initial build or license cost

AI-assisted development is reducing the upfront cost of custom software.

For some internal capabilities, this significantly narrows the historical cost advantage of buying.

Buying may still offer a lower initial cost, but the difference may be smaller than expected once implementation, integration, configuration, and customization fees are included.

Ongoing operational cost

Building means assuming KTLO — keep-the-lights-on — responsibility for the lifetime of the software.

That work consumes engineering capacity that could otherwise be invested in new initiatives.

Buying transfers much of that burden to the vendor, but replaces it with recurring licensing costs and potentially increasing customization or integration costs as organizational requirements diverge from the vendor's standard product.

Neither path eliminates ongoing cost.

They create different cost structures.

Governance and integration cost

This category is frequently underestimated, particularly when the initial prototype was inexpensive.

Connecting the capability to production data, enterprise identity, financial systems, customer information, security tooling, monitoring infrastructure, or regulated processes can quickly exceed the cost of producing the original application.

If the tool will eventually be maintained by someone other than its creator, additional documentation, testing, deployment, and ownership structures also become necessary.

These costs do not disappear because the first version was easy to build.

The common trap is:

teams anchor on creation cost, underestimate operational cost, and discover governance cost only after the capability has become important.

3. Time to Market

Historically, speed was one of the strongest arguments for buying.

That advantage has narrowed.

For many internal tools, building can now produce a useful first version as quickly as — or faster than — selecting, procuring, configuring, and implementing commercial software.

But two different timelines need to be distinguished:

time to working prototype

and

time to production-grade capability.

AI has dramatically compressed the first.

It has not necessarily compressed the second by the same amount.

Production readiness may still require security review, architecture work, integration, monitoring, recovery, data governance, compliance, support models, and operational ownership.

When comparing build and buy, be explicit about which timeline you are measuring.

A decision made on prototype speed while assuming production readiness will follow automatically is likely to underestimate the real investment.

4. Customization and Control

Custom software provides the highest degree of control over functionality, experience, data, architecture, and product evolution.

Commercial software requires compromise.

But control should be evaluated in relation to the gradient.

At Level 1, almost complete implementation freedom may be harmless.

At Level 3, uncontrolled change is itself a risk.

The organization may need auditability, release governance, testing standards, dependency controls, security review, and explicit ownership.

Paradoxically, greater technical control creates greater organizational responsibility.

The question is therefore not simply:

How much control do we want?

It is:

Are we prepared to exercise that control responsibly?

5. Resource Availability

Separate two questions that are often incorrectly treated as one.

Can we build it?

and

Can we operate it?

The first question concerns development capacity.

The second concerns sustained ownership.

A team may be entirely capable of creating the software and still lack the people, skills, processes, or organizational mandate required to run it once it becomes critical.

At higher gradient levels, ownership may require:

• operational support;
• observability;
• security expertise;
• release management;
• recovery planning;
• architecture governance;
• documentation;
• on-call capacity;
• service management.

If those capabilities do not exist internally, buying becomes more attractive.

That does not necessarily mean "do not build."

It may mean:

define the ownership model before the capability graduates, rather than after.

6. Maintenance

Internal software must be maintained for as long as the organization depends on it.

Dependencies change.

Infrastructure changes.

Security vulnerabilities emerge.

APIs are deprecated.

Employees leave.

Business rules evolve.

Third-party products transfer much of this maintenance responsibility to the vendor, although that introduces dependency on another organization's priorities and roadmap.

AI-powered vendor products add another dimension.

The underlying models may change. APIs may evolve. Model providers may be swapped. Data pipelines or runtime infrastructure may create forms of lock-in that are not obvious in the software license.

For AI-enabled products, assess:

• model dependency;
• API stability;
• data portability;
• infrastructure ownership;
• switching cost;
• the vendor's ability to change underlying models without materially changing the behaviour of the product.

7. Scalability

Scalability should be considered in two ways.

The first is traditional technical scalability:

Can the system support increasing users, transactions, data, markets, products, or domains?

The second is gradient scalability:

Can the capability move from Level 1 to Level 2 or Level 3 without requiring disproportionate architectural or operational reconstruction?

A tool that technically scales to thousands of users but lacks observability, ownership, recovery, and change control has not truly scaled.

It has merely accumulated dependency.

Also consider whether the capability has a "build once, use many times" characteristic.

If the same capability can be reused across multiple functions or domains, the economics of building may become substantially more attractive.

But reuse also increases dependency.

And dependency increases the consequences of failure.

8. Security and Compliance

Commercial products often arrive with established security programmes, certifications, audit processes, role models, access controls, and regulatory practices.

Those capabilities can represent a significant reason to buy.

Internal development means the organization assumes responsibility for establishing equivalent controls where they are required.

Again, the appropriate standard depends on the gradient.

A small Level 1 tool may reasonably rely on basic access restrictions.

At Level 3, the absence of auditability, role-based access, vulnerability management, data governance, and compliance controls is no longer an implementation detail.

It is a business risk.

Security architecture should therefore graduate with organizational dependency.

The final decision does not have to be purely "build everything" or "buy everything."

Modern architectures make composition increasingly practical.

An organization might buy commodity capabilities while building a differentiated experience around them.

It may use a commercial platform as a system of record while developing custom services on top.

It may combine several specialized tools through APIs rather than procuring a single monolithic platform.

It may begin with an internally built Level 1 or Level 2 tool and deliberately migrate to commercial software if the capability graduates.

Or it may buy initially and later internalize a capability once its strategic importance becomes clear.

The important thing is to understand the direction of travel.

Build and buy are architectural choices, not ideological positions.

Choosing to buy does not eliminate risk.

It transfers certain risks while introducing others.

A commercial software decision should therefore include its own rigorous evaluation.

1. Evaluate Cross-Functionally

Build a team representing the groups that will use, operate, integrate, govern, secure, and pay for the solution.

Depending on the capability, that may include:

• finance;
• product management;
• end users;
• software engineering;
• enterprise architecture;
• IT operations;
• back-office operations;
• security;
• compliance.

If an existing shadow tool already supports the capability, include its users.

They are likely to understand requirements that will never appear in a procurement document.

Define a short list of true must-haves to prevent the evaluation from becoming an indiscriminate feature comparison.

Also consider the organization's future roadmap.

The best software for today's requirements may be a poor choice if the capability is clearly heading somewhere else.

2. Evaluate Technical Requirements

Technical diligence should go beyond feature fit.

Consider:

• availability;
• performance;
• scalability;
• APIs;
• accessibility;
• security;
• compliance;
• user experience;
• integration;
• data portability;
• training;
• documentation;
• disaster recovery;
• support availability.

The higher the capability sits on the gradient, the more important these requirements become.

Security, compliance, resilience, and support may ultimately represent stronger reasons to buy than the product's visible feature set.

3. Assess the Vendor, Not Just the Product

Buying enterprise software usually means entering a multi-year relationship.

Evaluate the organization behind the product.

Consider:

• strategic trajectory;
• financial stability;
• size;
• engineering culture;
• transparency;
• product roadmap;
• access to leadership;
• customer support;
• industry experience;
• customer references.

Analyst viewpoints from organizations such as Gartner or Forrester can be useful, but they should complement rather than replace direct reference checks with comparable customers.

For AI vendors, traditional vendor diligence needs to go further.

A five-to-seven-year planning horizon assumes a degree of product stability that many AI vendors cannot yet demonstrate.

Assess:

• dependency on specific foundation models;
• ability to substitute underlying models;
• infrastructure ownership;
• data portability;
• API stability;
• switching cost;
• whether lock-in is contractual, architectural, or both.

A company may discover years into a vendor relationship that the real switching cost is not terminating the contract.

It is reconstructing the architecture surrounding the product.

4. Prove the Capability and the Economics

For significant investments, conduct a proof of concept.

Do not only test whether the software can demonstrate the desired features.

Test how it behaves in your environment.

Evaluate:

• functional fit;
• non-functional requirements;
• integration complexity;
• data requirements;
• operational tooling;
• vendor support;
• implementation philosophy;
• extensibility.

And evaluate the economics using total cost of ownership rather than license price alone.

Model implementation cost, licensing, integrations, customization, internal support, vendor support, upgrades, training, and likely switching costs.

Then compare that against the equivalent lifecycle cost of internal ownership.

The relevant question is not:

Which option is cheaper to start?

It is:

Which option creates the best balance of strategic value, control, risk, and lifecycle cost at the level this capability is likely to reach?

Build-vs.-buy decisions should be revisited.

But "review it periodically" is not sufficient guidance.

The more important trigger is graduation.

A capability moves from one level of the gradient to another when the organization's dependency changes.

Those moments can be subtle.

None of those changes necessarily arrive with an architecture review attached.

But they should.

Each one represents a potential change in the obligations surrounding the software.

A graduation event should therefore trigger a deliberate question:

Does the tooling, architecture, ownership model, and operating model still match the level of responsibility this capability now carries?

If the answer is no, the organization should decide whether to invest, re-architect, transfer ownership, replace the capability, or move toward a commercial product.

Do not wait for failure to reveal that the capability has already graduated.

AI changes the build-vs.-buy decision, but not because it makes buying obsolete.

It changes the economics of creating software.

That makes building rational for a much larger class of problems than it was previously.

But creation is only the beginning of the lifecycle.

As useful software attracts users, workflows, integrations, data, revenue, and organizational dependency, its obligations increase.

That is the central idea behind the Vibe-to-Product Gradient.

A tool can move from:

"If this breaks, I shrug."

to

"If this breaks, someone Slacks me."

to

"If this breaks, we miss money, reputation, or commitments."

to

"If this breaks, we're on the hook."

And each graduation changes the economics of owning it.

A strong build-vs.-buy decision therefore needs to answer more than whether an organization can build something faster or more cheaply than it can procure it.

It needs to establish:

Will the architecture survive where the capability is going?

Can the organization operate it when it gets there?

And what will it actually cost to own at that level?

The biggest risk is not necessarily choosing the wrong path at the beginning.

It is allowing expectations to keep graduating while the architecture, operating model, and ownership model remain where they started.

Build where differentiation warrants ownership.

Buy where accumulated expertise and responsibility transfer create greater value.

Compose where the best answer sits between the two.

And evaluate every decision against the capability you are likely to own tomorrow — not merely the prototype you can build today.