Build, Buy, or Integrate?

Every AI plan eventually reaches an acquisition decision: build the system, buy a product, or integrate a capability from a provider.

The wrong decision is expensive in different ways. Buying can force the operation into someone else’s workflow. Building can create a permanent product obligation around a commodity feature. Integrating can look flexible while quietly coupling the application to one provider’s behavior.

The answer should follow the source of advantage and the cost of ownership.

Buy when the workflow is standard

Buy a finished product when:

the job is common across many organizations,
the vendor’s workflow is acceptable,
differentiation is low,
implementation speed matters more than custom behavior,
and switching costs are understood.

Examples include transcription, generic meeting summaries, established support workflows, and mature document operations where the organization can adapt to the product.

The evaluation should use real cases, not the vendor’s demonstration. Test permissions, export, deletion, audit, failure handling, integration, and what happens when usage grows.

Buying is not avoiding implementation. Identity, data access, policy, user adoption, and operating ownership remain.

Integrate when the capability is a component

Integrate a model or specialized API when the capability belongs inside your product or process but the underlying intelligence is not the differentiator.

Examples:

model inference,
OCR and document parsing,
speech recognition,
embeddings and ranking,
content moderation,
or a specialized data service.

The organization owns the experience, context, workflow, and outcome. The provider supplies a bounded capability.

Design the integration around an internal contract. Preserve request and response versions. Validate structured output. Set time and cost limits. Capture enough evaluation data to compare alternatives later.

Provider independence is not achieved by wrapping every API in the same function. It is achieved by defining the behavior the product needs and maintaining tests that a replacement must pass.

Build when the system is the advantage

Build when the value comes from the organization’s distinctive workflow, data, judgment, product experience, or operating model.

Build is also appropriate when:

available products cannot satisfy permissions or deployment boundaries,
the workflow crosses systems in a unique way,
the capability must be deeply integrated into an existing product,
the organization needs control over evaluation and change,
or the expected volume makes product economics unattractive.

“Build” rarely means train a frontier model. It usually means build the application, context, retrieval, tools, state, evaluation, and controls around available models.

Compare the full cost

License price and development estimate are incomplete.

| Cost | Buy | Integrate | Build | | --- | --- | --- | --- | | Initial setup | Low to medium | Medium | Medium to high | | Workflow change | Often high | Low to medium | Designed to fit | | Ongoing product ownership | Shared with vendor | Mostly yours | Yours | | Differentiation | Low | Medium | High potential | | Provider dependency | Product-level | Capability-level | Model/infrastructure-level | | Control and evaluation | Vendor-defined | Mixed | Highest | | Switching | Data and workflow migration | API and behavior migration | Architecture-dependent |

Add internal review time, integration maintenance, support, security assessment, model usage, data movement, change management, and exit cost.

Avoid the false binary

Most useful systems combine all three strategies.

A company may buy identity and support software, integrate model and document APIs, and build the distinctive workflow that connects customer context to an operating decision.

The architecture should keep commodity concerns commodity. Differentiated behavior deserves direct ownership. High-consequence boundaries deserve control regardless of whether the core capability is purchased.

Run a short evidence phase

Before committing:

Assemble representative cases.
Define required behavior and constraints.
Test one or two credible products or providers.
Build the smallest custom probe needed to compare.
Estimate full operating cost and exit path.
Record the decision and assumptions that would cause it to change.

This prevents a six-month build of a solved problem and a three-year contract for a tool the operation cannot use.

The durable rule

Buy the standard workflow. Integrate the commodity capability. Build the part where your context, judgment, and experience create the value.

Then maintain enough evaluation and data portability that today’s choice does not become tomorrow’s unexplained dependency.

Put the decision into a real operating scenario

Frameworks become useful when they have to survive a specific week of work. Imagine a regional healthcare operator that wants to reduce the effort required to review incoming payer documents, identify meaningful policy changes, and route them to the right operational owner.

A vendor may offer excellent document extraction. Buying that capability makes sense if it can handle the document formats, preserve page-level evidence, meet the organization’s data requirements, and expose the extracted fields through an API. Rebuilding OCR and layout parsing would add cost without making the operator meaningfully different.

But the vendor probably does not understand which policy changes affect which locations, how the organization names service lines, who owns each exception, or what evidence an operations leader expects before acting. That layer is integration: connect the purchased extraction capability to the organization’s document taxonomy, definitions, permissions, and workflow.

The final review experience may deserve to be built. It can show the changed language beside the prior version, connect a policy to affected workflows, route open questions, record reviewer decisions, and preserve what happened for the next update. That interaction reflects how this specific organization operates. It may become an internal advantage even though several components underneath it were purchased.

This is why “build or buy” is usually the wrong level of abstraction. A useful system may include all three decisions:

| Layer | Likely decision | Reason | |---|---|---| | OCR and layout parsing | Buy | Mature capability; little differentiation | | Model access | Buy | Expensive frontier infrastructure | | Document ingestion | Integrate | Must connect vendor output to internal sources | | Policy taxonomy | Build | Encodes organization-specific meaning | | Review and routing experience | Build | Reflects the actual operating method | | Identity and audit | Integrate | Existing controls should remain authoritative |

The same pattern appears in finance, hospitality, reporting, and software products. Purchase commodity capability. Integrate it with the systems that already carry truth. Build the layer where the organization’s method, data, or customer experience creates an advantage.

Ask what happens after the first year

The initial implementation is only one part of the cost. A durable decision considers who will own configuration, vendor changes, model evaluations, support, data mapping, and incident response after launch.

Buying can look inexpensive until the team discovers that every workflow variation requires professional services. Building can look flexible until the original developer becomes the only person who understands it. Integration can look like a modest middle path until six providers change their APIs on different schedules.

Before committing, write down the operating obligations for each option:

Which team will notice when quality changes?
How will data be exported if the relationship ends?
Can the system be tested independently of the vendor’s demo environment?
What is the fallback when a provider is unavailable?
Which parts of the workflow will become difficult to change?
Does the expected usage make variable model or seat pricing material?

These are not reasons to avoid vendors or custom software. They are the questions that make the choice honest. The best answer is the one the organization can still understand, operate, and change after the launch team has moved on.

Make reversibility a first-class criterion

Uncertainty is unavoidable in a fast-moving market. Model quality changes, vendors revise products, pricing moves, and the team learns more about the workflow after people begin using it. A good acquisition decision leaves room to respond.

Reversibility does not require a provider-neutral abstraction around every API. That can create complexity before it creates value. It does require knowing which parts would be expensive to move and preserving the assets the organization cannot afford to lose: source data, corrections, evaluation cases, business definitions, workflow state, and the user experience built around them.

Ask the team to rehearse an exit before signing or building:

Can underlying records and feedback be exported in a usable format?
Are prompts, evaluation cases, and decision rules owned by the organization?
Is provider-specific behavior isolated enough to identify?
Can a temporary fallback preserve the critical workflow?
Would users have to relearn the entire experience after a component change?

The result may still favor a deeply integrated vendor. That is reasonable when its capability is strong and the relationship is worth the commitment. The difference is that the commitment has been made consciously, with the dependency visible.

The same principle applies to custom software. Code is not automatically portable merely because the organization owns it. Undocumented systems, obscure dependencies, and missing tests create a different form of lock-in. Reversibility comes from legible architecture, preserved data, representative evaluations, and a team that understands the boundaries.