Build, buy, extend or integrate? The AI decision that comes before the technology.

An executive asks whether the company should build its own AI. It sounds like a technology question. Usually it is several business questions packed into one sentence. Does the company need a new capability? Is its data too sensitive for an existing service? Does the process differentiate it from competitors? Is an incumbent platform missing a crucial workflow? Would internal ownership actually reduce future costs?

The answer changes depending on which question matters. A company trying to search internal documents and a SaaS business creating a new revenue-generating feature may use similar model APIs. They should not use the same investment logic.

01. Start by naming the job

Take a quotation workflow in a distribution business. Incoming PDFs require interpretation, product matching, exception handling, approval and an ERP update. Calling this an 'AI document extraction project' misses most of the work. The job is to turn a customer request into a valid, reviewed transaction with a traceable result.

Now compare that to an AI feature inside a B2B product. The job is to help a paying customer achieve a result in the software they already use. The design involves product differentiation, tenant isolation, support costs and retention. The same extraction model might be useful in both, but its value and constraints are different.

When the job is clear, the options become comparable. Without that clarity, teams evaluate model demos or vendor capabilities against a requirement no one has written.

02. Buy when the problem is common and the system is already governed

Packaged technology has real advantages. It has support, mature permissions, administrative controls, update cycles and an existing procurement pathway. A product such as an enterprise assistant may already connect to approved data sources and cover the everyday knowledge tasks the company wants to improve.

Buying is compelling when the requirement is common across many companies, customization needs are modest and the organization values a managed operational burden. The risks are licensing, dependency, limited product behavior and the possibility that a generic feature never quite fits the actual workflow.

A buy decision should still include technical work. Configure security carefully, map information permissions, test real user tasks, monitor usage and establish whether the vendor's terms fit the data. 'No code' does not mean 'no architecture'.

03. Extend when the existing platform owns the valuable records

Replacing a mature ERP or CRM to obtain one workflow is often a poor trade. The core platform may contain years of business rules, data contracts and user habits. Extensions can add a task-specific interface, automation or intelligence while preserving that system of record.

The important design question is where the extension stops. If it becomes a shadow database duplicating authoritative records, the organization may create the very problem it intended to solve. Well-designed extensions preserve ownership boundaries and bring the necessary workflow closer to the data it relies on.

04. Integrate when the work crosses systems

A surprising number of modernization problems are not product gaps at all. They are integration gaps. The ERP records transactions; the CRM records relationships; the shared drive contains evidence. Employees supply the missing connection through email and memory.

In this case, the most valuable software may be a small integration service with a review interface. It needs idempotent actions, permission-aware access, exception handling and reconciliation. It may use AI to interpret text, but the core value is the dependable transaction between systems.

Integrate is often the overlooked option because it does not sound like a grand transformation. It can still produce substantial operational value.

05. Build when the behavior is differentiating or cannot be bought responsibly

Custom engineering earns its place when requirements are specific: a proprietary product experience, unusual data relationships, regulated access boundaries, intricate approval paths, a private deployment requirement or a business model commercial software does not accommodate.

But custom means responsibility. Somebody must maintain the code, update dependencies, evaluate AI behavior after model changes, manage cloud costs and respond to incidents. Faster AI-assisted coding does not remove these obligations.

McKinsey's August 2026 survey reported that 32% of respondents had forgone at least one software purchase because coding agents enabled internal development. That is a useful signal of changing choices, not evidence that all SaaS will disappear. [1]

A decision record that a buying group can actually use

Evaluate each option on seven dimensions: business differentiation, total cost of operation, data and permission constraints, time to useful release, integration complexity, ability to change the product, and long-term ownership. The goal is not a mathematical score that gives false certainty. It is a documented discussion of what the organization values most.

A decision record should state the chosen approach, what it solves, the alternatives considered, why they were rejected, assumptions not yet tested and the trigger for revisiting the decision. That record will remain useful long after the tool names change.

When our recommendation would change

If the system is a commodity knowledge question-answering service and the organization already owns a capable enterprise platform, buying or configuring is likely preferable. If a company's core competitive advantage is its workflow, user experience or unique information structure, building can be justified. If the existing platform is genuinely unfit for its system-of-record responsibility, a larger modernization may be warranted. The point is that the architecture follows the organization, not the consultancy's preferred revenue model.

The practical rule: Buy the commodity. Extend what already anchors your operations. Integrate disconnected work. Build the capability that genuinely needs to be yours.

Sources and limitations

[1] McKinsey, The state of AI in 2026: On the road to ROI, August 25, 2026 (survey population and method should be reviewed before quoting figures).
[2] RSM, 2026 Middle Market AI Survey, July 21, 2026; all respondents were organizations already using AI. https://www.rsmus.com/insights/services/digital-transformation/rsm-middle-market-ai-survey
[3] Microsoft Learn, Available knowledge sources for agents; platform capabilities and licensing vary by environment. https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/knowledge-sources-overview