Build, buy or integrate? How to choose an AI solution for your business

Most businesses do not need to build an AI model. They may need to buy a useful product, configure it for their rules, connect it to approved company information or build a small amount of custom software around an existing model.

That distinction matters. “Build or buy?” sounds like a choice between a boxed product and a team of scientists training a model from the beginning. In practice, a useful business solution has several layers: the model, the application, your information, connections to other systems, business rules, permissions, monitoring and support.

The sensible answer is often mixed:

Buy the common capability. Configure the workflow. Integrate the systems that hold the facts. Build only the part that is genuinely specific to your business.

The executive answer

• Buy when the problem is common, the product fits most of the workflow and the vendor can operate it better than you can.
• Configure when an existing product works after setting roles, templates, knowledge, rules and approval paths.
• Integrate when the missing value is a safe connection between the product and your customer, finance, inventory, document or reporting systems.
• Build custom software when the workflow is strategically important, meaningfully different and supportable over time.
• Do not proceed yet when the problem, data, owner, success measure or legal basis is unclear.

Treat this as a sourcing decision for a complete operating capability—not a contest between software demonstrations.

Why the question is rarely binary

Consider a customer-service assistant. A business could:

• buy a helpdesk product with built-in AI;
• configure approved answers and escalation rules;
• integrate it with order and delivery records;
• build a custom customer portal around a third-party model; or
• combine all four.

The model may be the least distinctive part. The difficult value often sits in knowing which records the assistant may use, which source is authoritative, when a person takes over and how the answer becomes part of the existing customer process.

UK government AI procurement guidance recognises that AI can be built from scratch, bought off the shelf or added to systems already in use. It advises buyers to assess data availability, benefits, risks, integration and lifecycle management before choosing a route. Although written for public procurement, these are useful disciplines for private businesses too. Read the UK guidelines for AI procurement.

Define the capability before choosing the source

Write the requirement without a product name:

When a customer asks about an existing order, employees need a draft reply using the latest approved order and delivery records. The reply must show its sources, avoid promising a new delivery date and be approved by an employee before sending.

That description allows several solutions to compete. “Buy an AI chatbot” quietly assumes the answer before the business has described the problem.

For each proposed capability, define:

• the user and business outcome;
• the trigger and expected result;
• the information required;
• the system of record;
• the actions that are permitted;
• the decisions that remain human;
• the expected volume;
• the acceptable failure and response time; and
• the evidence that will justify continuing.

If you cannot define the work yet, use the guide to choosing a business process for AI automation first.

COMPARE THE COMPLETE JOB

A clean extraction demo is the starting point, not the buying decision.

THE DEMO

Clean invoice→Neat fields

Useful evidence, but only one part of the process.

→

THE BUSINESS TEST

REAL INPUTSNormal and awkward documents

CONTROLChecks, roles and human approval

BOUNDARYStorage, AI processing and access

HANDOFFDestination, errors and traceability

→

THE DECISIONA measured pilotContinue, change or stop using agreed evidence.

Option 1: buy an off-the-shelf product

Buying is usually strongest when many organisations need substantially the same capability: meeting transcription, email drafting, document signing, helpdesk ticketing or common accounting tasks.

Advantages

• Faster access to a working product.
• Lower initial development responsibility.
• Vendor-managed updates, availability and basic support.
• Established interfaces, documentation and training.
• Costs that may be easier to test at small scale.

Limits

• The product may impose its workflow on your team.
• Important connections may be unavailable or priced separately.
• AI features may be bundled into a larger subscription.
• Data location, retention or model-training terms may not fit your requirements.
• The vendor controls its product roadmap, limits and future prices.
• Exporting configuration, history or knowledge may be difficult.

Buying does not remove management responsibility. The business still decides whether the product is suitable, which information it may process and which outputs require review.

Option 2: configure an existing product

Configuration uses capabilities the product already provides: roles, templates, custom fields, approved knowledge, routing rules, prompts, thresholds and approval steps.

This is often the best first route because it adapts a maintained product without creating a separate application. It works when the product's underlying assumptions are close to the way your business operates.

Ask the vendor to demonstrate your workflow, not its favourite workflow. Use representative inputs, including the awkward cases. Confirm which behaviour is configurable and which would require custom development.

Be wary of configuration that quietly becomes programming without the engineering practices, testing or ownership custom software requires.

Option 3: integrate products and business systems

Integration is appropriate when separate systems already contain the capability and information, but employees repeatedly move information between them.

Examples include:

• reading an order in an ERP before preparing a WhatsApp reply;
• comparing completed deliveries with accounting records;
• combining branch sales, returns, stockouts and targets into a weekly brief;
• sending an approved document record to an accounting system; and
• creating a service ticket from a checked customer conversation.

Integration can preserve the systems employees already know. It can also create a dependency chain: if the CRM, connector, AI service or identity system fails, the complete process may fail.

Define:

• which system remains authoritative;
• what may be read or written;
• how identities and permissions carry across systems;
• what happens when records disagree;
• how retries avoid duplicate actions;
• how failures are detected; and
• who supports each part.

The value of integration is not that “everything talks to everything.” It is that one defined piece of work no longer depends on a person copying the same information through several systems.

Option 4: build custom software

Custom work becomes more defensible when the capability is important, the workflow is materially different from available products and the organisation can support the result.

Custom does not necessarily mean training a foundation model. It may mean building an application that uses an existing model through an API, runs an open model in a controlled environment, applies company-specific rules, connects unusual systems or presents a specialised approval experience.

Reasons that can justify custom work

• The workflow creates a genuine operational or customer advantage.
• Existing products cannot support a critical rule or integration.
• Data-control or deployment requirements rule out available products.
• The volume and long-term economics support the investment.
• The business needs control over the interface, logic or roadmap.
• A capable team or partner can maintain it.

Reasons that do not justify it by themselves

• “We want to own AI.”
• A product demo did not use your preferred colours.
• A vendor subscription looks expensive when compared only with the initial build estimate.
• The technical team wants an interesting project.
• Management assumes custom automatically means secure, accurate or future-proof.

Custom software replaces vendor dependency with responsibilities of your own: security, reliability, evaluation, upgrades, incident response, documentation, staff continuity and support.

Compare the complete layers

Do not compare a monthly product licence with a one-time development quote. They cover different responsibilities.

Many solutions buy the model and application, configure the knowledge and workflow, integrate company systems and build a small custom control or interface. Label each part so responsibility is clear.

Apply seven decision tests

1. The common-problem test

If thousands of businesses perform the same task in much the same way, buying deserves a strong presumption. Payroll, document signing and meeting transcription are examples where established products may cover most requirements.

Do not rebuild a commodity unless another requirement—such as unusual integration, data control or economics—provides a specific reason.

2. The differentiation test

Would doing this capability unusually well improve what customers buy from you or how the business competes?

A generic email-writing assistant is unlikely to be strategic. A system that combines proprietary operational knowledge, unusual scheduling constraints and customer commitments may be closer to the business's distinctive capability.

Be demanding about the word “strategic.” An important internal process is not automatically unique.

3. The fit-gap test

List the requirements an existing product meets, partly meets and does not meet. Separate essential gaps from preferences.

If a product covers 85% of the workflow, changing a minor internal habit may be more sensible than custom-building the final 15%. If the missing 15% contains the approval, system connection or business rule that creates the value, integration or custom work may be justified.

4. The data-and-control test

Map what information leaves each system, where it is processed, who can access it, how long it is retained and whether it may be used to improve a provider's models.

For personal data, apply the law in the relevant jurisdictions. Kenya's Office of the Data Protection Commissioner emphasises lawful processing, data-subject rights, appropriate safeguards and Data Protection Impact Assessments where required. Review the ODPC's guidance on AI and personal data.

Neither buying nor building is automatically safer. A mature vendor may operate stronger controls than a small internal team. A custom deployment may provide important control unavailable in a standard product. Examine the actual design and evidence.

5. The lifecycle-cost test

Compare costs over a realistic period. Include:

• discovery and procurement;
• licences or usage;
• configuration and integration;
• data preparation;
• testing and evaluation;
• security, privacy and legal work;
• training and change management;
• monitoring and support;
• model or platform changes;
• internal management time; and
• exit or replacement.

Estimate cost per useful unit where possible: per reviewed invoice, resolved routine enquiry, completed report or approved order. A low token price can still support an expensive workflow if people spend substantial time fixing the result.

6. The maintenance test

Ask who will still care for the solution in two years.

For a product, examine the vendor's support, financial stability, roadmap and service commitments. For custom work, identify who will understand the code, integrations, data, tests and operating decisions after the original builders move on.

If the organisation cannot maintain the distinctive part, it does not truly control it even when it owns the source code.

7. The exit test

Before entering, explain how the business could leave.

Can you export records, configuration, prompts, evaluations and activity history in usable formats? Can another model or vendor replace the current one? What happens to retained data and backups? Which integrations must be rebuilt?

Avoiding all dependency is unrealistic. Choose dependencies deliberately and keep the information or business logic you cannot afford to lose portable where practical.

Worked example: weekly branch reporting

Consider an illustrative business with six branches. Every Friday, managers export sales, stock and returns, then finance adds targets and prepares a Monday report.

Management wants “a custom AI reporting platform.” The sourcing analysis produces a more modest answer:

• Keep the existing sales, inventory and accounting products as systems of record.
• Use supported exports or APIs rather than replacing them.
• Build or configure a scheduled integration that reconciles agreed measures.
• Use an existing model to prepare a draft explanation of material changes.
• Build a small approval view showing sources, timestamps and unresolved discrepancies.
• Require the finance or operations owner to approve the brief.

The company is not building a model. It is building the specific connection, reconciliation and approval workflow that off-the-shelf tools do not provide together.

The pilot should compare report-preparation time, corrections, missing inputs and whether the brief leads to earlier action. If managers still debate the definition of a return, the project must resolve that business rule before scaling.

A decision table for leadership

This is a starting point, not a formula. Procurement, operations, IT, security, finance and the responsible business owner should challenge the decision from their perspectives.

Questions to put in the decision paper

Before approval, leadership should be able to answer:

1. What business outcome are we buying?
2. Which parts are product, configuration, integration and custom work?
3. Which information will the solution use?
4. What must remain under human authority?
5. What evidence must a pilot produce?
6. What is the three-year expected cost range?
7. Who operates and supports every layer?
8. What happens when a provider, model or source system changes?
9. How do we retrieve our records and leave?
10. Why is this route better than simplifying the present process?

Buy convenience. Build distinction. Integrate carefully.

The aim is not maximum ownership or minimum monthly cost. It is a capability the business can trust, afford and operate.

Start with the work. Buy common capabilities from credible providers. Configure them around clear roles and information. Integrate only the systems the job requires. Build when the distinctive value is real and the maintenance responsibility is accepted.

Then test the complete workflow before expanding it. A good sourcing decision survives contact with ordinary work, not only the procurement presentation.

Research and helpful links

• UK Government guidelines for AI procurement
• UK Government guidance on assessing whether AI is the right solution
• NIST AI Risk Management Framework Playbook
• OECD: AI adoption by small and medium-sized enterprises
• Kenya Office of the Data Protection Commissioner guidelines

Research checked on 20 September 2026. Procurement, contract, privacy and sector obligations differ; obtain appropriate professional advice for the proposed system and jurisdictions.