The build-or-buy decision is rarely a choice between “cheap software” and “expensive development.” It is a choice about speed, control, differentiation, responsibility and the cost of changing the system later.

For most small and medium-sized businesses, the strongest answer is hybrid: buy standard capabilities and build only the layer that reflects a unique process or competitive advantage.

Start with the process, not the product category

Write down the exact outcome, users, data, integrations, error cost and expected volume. “We need an AI platform” is not a requirement. “Classify incoming service requests, retrieve an approved answer and prepare a draft in the CRM” is.

If the process is still vague, use the selection method in AI Automation for Small Business: Where to Start before comparing vendors or development estimates.

The NIST AI RMF Core organises AI risk work into Govern, Map, Measure and Manage. Those responsibilities remain with the organisation whether the model is purchased, accessed through SaaS or developed internally.

When ready-made SaaS is the better choice

Buy when the process is common, the required workflow matches the product and speed matters more than differentiation.

  • The business problem is standard across many companies.
  • A controlled pilot can begin with configuration rather than engineering.
  • Required integrations are already supported and documented.
  • Data sensitivity fits the provider's contractual and technical controls.
  • The team does not want to operate its own application, evaluations and incident response.
  • Export and exit conditions are acceptable.

SaaS usually reduces initial delivery time. It does not remove implementation work. Permissions, data mapping, acceptance criteria, employee training and ongoing quality checks still belong to the buyer.

When custom AI is justified

Build when the workflow is strategically distinctive or the constraints cannot be handled safely through configuration.

  • The process is a source of competitive advantage.
  • The system must coordinate several internal sources of truth and legacy APIs.
  • Rules, approval paths or audit requirements are unusually specific.
  • The company needs model portability, custom evaluations or detailed action logs.
  • Volume makes per-seat or per-operation pricing structurally expensive.
  • The organisation can fund maintenance, security, monitoring and ownership after launch.

Custom does not have to mean training a foundation model. It often means building the orchestration, retrieval, validation, permissions and interface around an existing model.

Compare total cost, not purchase price

Ready-made SaaS costs

  • subscription, seats and usage tiers;
  • implementation and data migration;
  • integration middleware or premium connectors;
  • administration, review and employee training;
  • price increases and additional modules;
  • export, migration and parallel running during exit.

Custom AI costs

  • discovery, architecture and development;
  • data preparation and integration;
  • testing, evaluations and security review;
  • model and infrastructure usage;
  • monitoring, support and incident response;
  • continuous changes when models, APIs and business rules evolve.

The same life-cycle principle used in How to Calculate the ROI of AI Automation should be applied to both options over the same volume and time horizon.

Data control and vendor due diligence

A contract does not replace technical verification. Map what data enters the product, where it is processed, who can access it, how long it is retained, whether it may be used to improve a shared service and how it can be deleted or exported.

The ICO AI and Data Protection Risk Toolkit includes due-diligence checks for processors and third parties, documented security testing, data-subject rights and the accuracy level a buyer is prepared to accept before procurement.

CISA's Secure by Demand Guide gives software buyers questions for evaluating whether a supplier treats security as a product requirement. Use those questions during selection, not after signing.

For personal and confidential data, use the practical controls described in How to Protect Company Data When Using AI.

Vendor lock-in is a measurable design choice

Lock-in is not simply “using a vendor.” It is the cost and difficulty of leaving.

  • Can data and configuration be exported in documented formats?
  • Can the model endpoint be replaced without rebuilding the full workflow?
  • Who owns prompts, evaluations, embeddings and workflow logic?
  • What happens to logs and customer data after termination?
  • Can the business run both systems during migration?
  • How much notice is given for pricing, API or feature changes?

The European Commission's Cloud Sovereignty Framework explicitly considers the ability to sustain operations if vendor support is withdrawn or disrupted. Even a small company can apply that test by writing an exit plan before procurement.

A practical case from my own work

For my multilingual publishing workflow, I did not build a task board or a messaging platform. Trello already provides visible workflow states, and Slack already provides team communication.

I used ready-made services for those standard functions. I kept a custom layer around the website API because the article schema, three language adaptations, cover upload rules, internal links and page checks are specific to this site.

This hybrid design avoids rebuilding commodity software while preserving control over the part that differentiates the process. If the task board changes, the article data and publication checks do not need to be redesigned from zero.

A seven-question decision matrix

  1. Process fit: can a product support the real workflow without forcing unsafe workarounds?
  2. Time to value: how quickly can each option deliver a controlled pilot?
  3. Three-year cost: what is the life-cycle cost at realistic volume?
  4. Data control: are location, access, retention, deletion and training use acceptable?
  5. Change cost: how expensive is a new rule, integration or approval step?
  6. Exit: can data and workflow logic move to another provider?
  7. Operating ownership: who monitors quality, security, incidents and changes?

Score both options with evidence. A polished demo is not evidence of process fit, and a low development estimate is not evidence of maintainability.

A sensible default for small and medium-sized businesses

  1. Buy or configure the common capability.
  2. Keep company data in a controlled source of truth.
  3. Place permissions, validation and logs outside the model where practical.
  4. Measure the limitations during a narrow pilot.
  5. Build only the layer that cannot be bought safely or economically.
  6. Preserve an export path and test it before dependency becomes critical.

This approach can shorten launch time without surrendering control over the business logic that matters.

Questions and answers

Is custom AI always more accurate?

No. Accuracy depends on the use case, data, retrieval, rules, evaluation and operating controls. A configured SaaS product can outperform a weak custom implementation.

Is SaaS always cheaper?

It is often cheaper to start. At high volume, with many seats or extensive customisation, recurring charges and integration constraints can change the comparison.

Can a business start with SaaS and build later?

Yes, if it keeps its data portable, documents the process and avoids placing all workflow logic inside proprietary features that cannot be exported.

Who is responsible for AI risk when software is purchased?

The supplier has responsibilities, but the buyer still decides how the system is used, what data it receives and which outputs affect people or operations.

What should be tested before signing a long contract?

Real process fit, accepted-output quality, permissions, security controls, integration behaviour, total cost at expected volume, data export and the termination process.

Sources