Build, Buy or Integrate an AI Capability?

Decide whether to build, buy or integrate an AI capability

Building an AI capability means owning its evaluation, model changes and incidents for years; buying means accepting a vendor’s roadmap and data terms; integrating means owning the joins between products. Answer seven questions about one capability and the tool scores all three, names the leading option and shows the answers that decided it, so the trade-off is explicit before anyone commits budget.

This is a good fit if…

You are a CTO or product sponsor with an AI opportunity and a team divided between building and buying.

A vendor demo looked convincing, and you want to test the decision against data rules, integration and lock-in.

Your team wants to build, and you need to check whether it can maintain what it builds.

How it runs

Describe one capability

For example, drafting support answers from documentation. Not “AI” in general.

Answer seven questions

Differentiation, product fit, data rules, integration, maintenance capacity, time and lock-in.

Test the deciding factors

If the result is a close call, check the two or three answers that decided it before committing budget.

Three options, defined

Build. Your team designs, builds and runs the capability, using models and cloud services as components. You own the logic, the evaluation and every incident.
Buy. You adopt an existing product largely as it is, configured for your organisation. The vendor owns the roadmap; you own adoption and the data terms.
Integrate. You connect existing products to your systems and to each other, and own the joins: data flow, permissions, controls and glue code.

Most real decisions end up as a mix, but naming the leading option for each capability keeps the trade-offs honest.

What the seven questions test

Differentiation. If the capability is part of what makes you different, owning it matters. If it is a common business function, vendors already compete to provide it well.
Product fit. If a product covers most of the need, buying is hard to beat. If it covers part, integration fills the gaps.
Data sensitivity and residency. Strict rules narrow the products you can use and favour control over where data goes.
Integration complexity. When the capability must connect to many or complex systems, most of the work is in the joins, whatever you buy.
Maintenance capacity. The decisive question for build. Without a team that can run evaluation, handle model changes and respond to incidents for years, building leaves you with something nobody can run.
Time pressure. Weeks favour something that exists; a quarter or two allows integration and modest building.
Lock-in tolerance. Low tolerance favours owning the logic, or at least the interfaces between products.

Each answer adds points to one or more options, and some subtract. The result shows all three scores, the leading option, the answers that most separated it from the runner-up, and the answers pulling the other way. When the margin is two points or fewer, the tool calls it a close call.

The cost that build decisions forget

The first release of a built AI capability is the cheap part. After it come model and API changes that shift behaviour, an evaluation set that needs maintaining as the product changes, cost and latency that need watching, and incidents that need someone on call. This lifetime operating effort is why the tool weights maintenance capacity so heavily, and why “we can build it in a month” is rarely the right question.

Illustrative example

Illustrative example, not a client engagement. A B2B software company wants an assistant in its support tool that drafts answers from product documentation and past tickets. The CTO answers: somewhat differentiating; existing products cover part of the need; data rules are strict, because enterprise customers’ contracts restrict where their ticket data can go; integration with several internal systems; partial maintenance capacity; needed within a quarter or two; some lock-in acceptable with an exit route.

The scores are integrate 14, build 5, buy −2. The deciding factors are partial product fit, partial maintenance capacity and tolerance for lock-in with an exit route. The factor pulling towards build is the strict data rule, so the integration has to keep ticket data within approved services and regions. That becomes the first requirement in the scope.

Assumptions and limitations

This is a structured first pass, not an architecture review. It does not compare specific vendors, prices or contract terms, and it cannot see your existing architecture or team skills beyond what you report. The scoring reflects common trade-offs; your context may weigh one factor far more than the tool does, for example a regulatory requirement that rules out an option entirely.

What to do next

If you need someone to own the decision, the architecture and the roadmap that follows, that is a fractional AI CTO engagement. If integrate leads, see AI workflow automation and systems integration or, for controlled tool access between AI and your systems, MCP integration. If buy leads, AI tool rollout and adoption support covers getting a chosen product used well. If you are earlier than this and still choosing which capability to pursue, see the AI readiness and implementation roadmap.

Questions buyers ask

Isn't building always more flexible?

More flexible, yes; cheaper to own, rarely. A built AI capability needs an evaluation set, monitoring, someone to handle model and API changes, and incident response, for as long as it runs. If nobody can do that, flexibility turns into a system nobody dares change. The tool penalises build heavily when maintenance capacity is missing.

What exactly does integrate mean here?

Connecting existing products to your systems and to each other, and owning the joins: the data flow, permissions, controls and the glue code between them. It often uses product APIs, workflow automation or protocols such as MCP. It keeps more control than buying outright, with less to maintain than building.

How should we think about vendor lock-in?

Ask what it would cost to leave: exporting your data, rebuilding prompts and workflows, retraining people. You can reduce lock-in without building everything, for example by keeping your own interfaces between your systems and the vendor, so the vendor can be replaced behind them.

Can the answer change over time?

Yes, and it often should. A common path is to buy or integrate first to learn what the capability needs to do, then build the parts that turn out to be genuinely differentiating. Re-run the tool when the product market, your data rules or your team change.

Use the worksheet or discuss your requirement

A short, non-confidential description is enough to start. I read every brief personally and reply within two business days, including when the answer is that I am not the right fit.

Decide whether to build, buy or integrate an AI capability