The AI Build-or-Buy Matrix: Decide What Deserves Custom Engineering

Start with the decision, not the model

The build-or-buy debate is often framed as a technical choice: proprietary model or external API, open-source stack or software subscription, internal team or vendor implementation. That framing arrives too late. Leaders should first define the business decision the AI system will improve, the value of improving it and the consequences of failure. A customer-support assistant that drafts replies for human approval presents a different risk profile from a system that sets credit limits, even if both use the same foundation model. One may save four minutes per ticket; the other can alter a customer’s financial prospects and expose the company to regulatory action.

A practical matrix should score each use case across five dimensions: differentiation, data sensitivity, integration burden, available talent and switching costs. Use a five-point scale, but do not pretend the result is mathematical truth. The score is a forcing mechanism for exposing assumptions. A workflow rated five for strategic differentiation and four for data sensitivity deserves a different architecture from a generic meeting summariser rated one on both. Weight the dimensions according to the company’s economics and obligations; a hospital may double the weight of data sensitivity, while an online retailer may emphasise integration and latency.

The unit of analysis matters. Do not ask whether the company should ‘build AI’. Break the product into layers: user experience, workflow logic, retrieval, data pipelines, evaluation, model serving and the underlying model. Most sensible strategies are hybrid. A company can buy foundation-model access, build its retrieval and permissions layer, and retain ownership of the customer-facing workflow. The objective is not maximum customisation. It is to place scarce engineering effort where ownership creates durable advantage.

Differentiation determines where custom engineering pays

Custom engineering is justified when the AI capability changes why customers choose the product, not merely how efficiently the company operates. A legal-technology provider whose core promise is superior contract analysis may need proprietary taxonomies, evaluation sets, retrieval logic and user interactions. A manufacturer using AI to summarise internal meeting notes probably does not. Ask a blunt question: if a competitor bought the same vendor product next week, would the advantage disappear? If the answer is yes and the capability influences revenue, retention or pricing power, ownership becomes more valuable.

Differentiation should be measured rather than asserted. Estimate the commercial effect of a ten-percentage-point improvement in task success. If raising accurate parts identification from 80% to 90% would prevent £3 million in annual warranty claims, a custom vision pipeline may be defensible. If improving an internal search assistant by the same margin saves 30 employees ten minutes a week, the annual benefit may be below £15,000. In the second case, a £60-per-user subscription can still be expensive, but an engineering team is unlikely to be cheaper.

Even strategic products rarely require a model trained from scratch. Training a frontier model can cost tens or hundreds of millions of pounds before data acquisition, evaluation and ongoing inference. Fine-tuning, retrieval-augmented generation and deterministic workflow controls often capture most of the useful differentiation at a fraction of that cost. Build the elements that encode domain knowledge and customer experience; buy the commodity intelligence underneath until evidence shows that it is the constraint.

Data sensitivity changes the economic calculation

Sensitive data is not an automatic argument for building, but it raises the burden of proof for buying. The relevant questions are specific: where are prompts and outputs stored, are they used for training, how long are logs retained, which subprocessors receive them, and can the system respect deletion and residency requirements? A vendor offering zero-retention processing, regional hosting, customer-managed encryption keys and auditable access controls may be safer than a hurried internal deployment of an open model on poorly governed infrastructure.

Classify both the input data and the generated output. Personally identifiable information, medical records, payment details, unreleased financial results and proprietary designs require tighter controls than public marketing copy. Outputs can also create risk through inference: a staffing model may reveal protected characteristics indirectly, while a sales assistant may reproduce confidential customer terms. For high-impact systems, budget for red-team testing, audit trails, human review and rollback mechanisms. Those controls can add 20–40% to implementation effort, regardless of whether the model is bought or built.

The strongest case for custom deployment appears when data cannot legally or commercially leave a controlled environment, or when proprietary data is itself the moat. An industrial company analysing sensor streams from patented machinery may run a smaller model within its own cloud tenancy or at the edge. Yet leaders should distinguish control from ownership. Running an open-weight model privately can reduce data exposure without funding model research; buying managed infrastructure inside a virtual private cloud can provide isolation without creating a 24-hour model-operations function.

Integration burden is where budgets break

AI demonstrations are cheap because they avoid the systems that make production difficult. A chatbot can be assembled in days; connecting it reliably to identity management, customer records, inventory, permissions, billing and audit logs may take six months. Integration burden should therefore include the number and quality of dependent systems, the need for real-time responses, transaction reversibility and the cost of errors. Reading from a product catalogue is simpler than issuing refunds or changing delivery addresses.

Buying does not eliminate integration. A packaged AI product may cover 70% of a workflow but force employees to switch interfaces, duplicate data or accept rigid approval rules. The missing 30% can consume most of the project budget. Before signing, run a two-week technical discovery and map every required data source, action, permission boundary and failure path. Demand evidence for the vendor’s connectors: ‘Salesforce integration’ may mean a mature bidirectional synchronisation service, or merely a button that exports a note.

Custom engineering wins when the workflow crosses several systems and those connections embody company-specific operating logic. Buying wins when the process is standard and the vendor has already absorbed the integration cost across hundreds of customers. Payroll assistance, transcription and basic document extraction are increasingly standardised. Dynamic pricing across bespoke inventory, regional constraints and contractual commitments is not. The matrix should penalise options that require brittle middleware, manual reconciliation or unsupported custom code, even when their headline licence price looks attractive.

Talent and operating capacity set the real boundary

An organisation does not possess an AI capability because it hired two machine-learning engineers. Production systems require product management, data engineering, security, platform operations, domain expertise and evaluation. A modest internal team of six experienced specialists can easily cost £700,000–£1.2 million annually in salary, benefits, recruitment and infrastructure in the UK, before opportunity cost. If the expected three-year value of a use case is £500,000, building is not strategic ambition; it is poor capital allocation.

Assess talent against the actual layer being built. Most companies do not need researchers capable of inventing new architectures. They may need engineers who can design retrieval systems, create evaluation datasets, monitor model drift and integrate APIs safely. The talent question is also about continuity. If one engineer understands the entire prompt-routing and data pipeline, the company has created a key-person risk. Documentation, automated tests, incident playbooks and ownership rotation are part of the build cost, not optional housekeeping.

Buying transfers some operational burden, but not accountability. Vendors monitor infrastructure and release models; customers must still define acceptable behaviour, test updates and manage users. A credible supplier should provide service-level commitments, security documentation, model-change notices and export tools. Internally, name a product owner and establish monthly quality reviews. Without those roles, purchased AI becomes shelfware or an uncontrolled shadow system, while custom AI becomes an experiment that nobody can safely maintain.

Switching costs must be priced before adoption

AI vendors can create lock-in through more than contracts. Prompts, evaluation suites, embeddings, fine-tunes, agent tools and workflow configurations may depend on proprietary formats. A low introductory price can become expensive once millions of documents have been indexed or hundreds of employees have redesigned their work around the product. Model pricing also changes quickly. A service costing £20 per million tokens today may be displaced by a cheaper model, but migration is difficult if application logic is fused to one provider’s API.

Estimate an exit cost alongside the three-year total cost of ownership. Include data export, re-indexing, prompt and tool rewrites, regression testing, user retraining and parallel operation during migration. For a departmental assistant, exit may cost £20,000 and take a month. For an AI layer embedded in claims processing, it can exceed £1 million and require two quarters. Contractual protections should cover data portability, deletion certification, notice periods for material model changes, price-review mechanisms and continued access during transition.

Architecture can preserve options without creating needless abstraction. Keep business rules and evaluation datasets outside vendor platforms; use a thin adapter around model APIs; store source documents in company-controlled repositories; and log model versions with outputs. Avoid promising frictionless portability across models, because behaviour varies even when interfaces look similar. The goal is not zero switching cost. It is a known, manageable cost that remains proportionate to the value received.

Use a scored matrix, then test the answer

Create one row for each product path: buy a packaged application, buy a model API and build the workflow, deploy an open-weight model, or develop a deeply custom system. Score each option from one to five against strategic differentiation, data control, integration fit, talent feasibility and switching exposure. Add three financial fields: first-year cost, three-year cost and credible value at risk. A high score without an economic case is still a no. Likewise, the cheapest option may fail if it cannot meet a non-negotiable regulatory or reliability threshold.

Consider a mid-sized insurer automating claims triage. A packaged tool may score well on speed and talent requirements but poorly on integration with a 20-year-old policy platform. A fully custom system may maximise control but require a £1.5 million first-year team. An API-led hybrid could cost £400,000, preserve internal workflow ownership and reach production in four months. If it reduces handling time by eight minutes across 200,000 claims, at a loaded labour cost of £30 per hour, the annual capacity value is roughly £800,000 before accounting for error reduction.

Treat the matrix as a hypothesis and validate it with a bounded pilot. Use representative data, a fixed evaluation set and explicit acceptance criteria such as 92% routing accuracy, under three seconds’ latency and fewer than one severe error per 10,000 cases. Measure human override rates and total cost per completed task, not just model accuracy. Set a decision date and a kill threshold. Custom engineering deserves funding when the pilot proves that ownership improves economics, control or differentiation. Everything else should be bought, adapted or postponed.