Article · Decision Framework

Build vs Buy for AI

The decision framework for whether to buy a packaged AI product, use a vendor API with light wrapping, build a custom system on your own data, or hire a vertical AI vendor for the function. Seven criteria, a side-by-side comparison, and the hybrid path most companies actually need.

By Aleksi Stenberg · 16 May 2026 · 11 min read

Summary

"Build or buy AI" is the wrong framing because it assumes two options. There are four: buy a packaged AI SaaS product, use a vendor model API with light glue, build a custom AI system on your own data, or hire a vertical AI vendor that delivers the system in your environment. Each has a sensible application and each has a failure mode.

The decision turns on seven criteria. Data sensitivity. Scale. Vendor risk. Time-to-value. IP value. Integration complexity. In-house capability. This article works through each criterion, shows where buying wins, where building wins, and how most Nordic mid-market companies in 2026 end up running a hybrid stack across two or three of the four options.

The Framing Problem

Almost every "build or buy AI" conversation starts with a false binary. The CEO heard from a peer that they should be doing AI. The CFO heard that custom AI is expensive. The CTO heard that buying AI carries data risk. Within a quarter the company has spent forty hours debating an artificial choice and has shipped nothing.

Build vs buy for AI is the decision framework that determines which of four paths fits a given AI use case. Buy a packaged AI SaaS product. Use a foundation model API with thin glue. Build a custom AI system on your own data. Or hire a vertical AI vendor to build and run the system inside your environment. The right answer depends on the use case, not on a company-wide policy.

Treating build vs buy as a single company decision is what produces the forty-hour debate. Treating it as a per-use-case decision is what produces shipped systems. A typical mid-market company in 2026 buys for general productivity, uses a model API for customer-support drafting, and builds a custom system on top of its own data for the workflow that touches sensitive customer information. The same company runs all three at once.

The framework below is designed to be used per project. Score each candidate AI initiative on seven criteria. Sum the scores. The shape of the answer tells you which of the four paths fits.

The Four Options

Before the criteria, the options themselves. The differences between them often get blurred in conversation, which is part of why the framing problem persists.

Option	What it is	Typical cost shape	Who owns the IP
Packaged AI SaaS	A product where AI is the core feature (Intercom Fin, Gong, GitHub Copilot, Glean)	Per seat or per usage, monthly	The vendor
Model API plus glue	Direct access to a foundation model (OpenAI, Anthropic, Google) with thin custom code around it	Per token, plus light engineering	Mixed: model output is yours, model weights are the provider's
Custom build	A bespoke AI system using foundation models as components, your data as context, fully owned by the client	Project cost to ship, then API costs to run	The client
Vertical AI vendor	A specialist firm that builds and operates an AI system for a specific function inside your environment	Project plus ongoing service	Often the vendor (read the contract)

The four options are not stages of maturity. They are different products with different economics. A small marketing team running on packaged SaaS is making a sensible choice. A regulated financial institution building its customer-facing AI in-house is making a sensible choice. The mistake is applying one path to every project regardless of fit.

Buying gets you to demo. Building gets you to differentiation. Most companies need both, sequenced correctly.

The Seven Decision Criteria

Score each criterion from 1 (strongly favours buy) to 5 (strongly favours build) for the specific use case in front of you.

Data sensitivity Does the AI need to read regulated data (personal data under GDPR, financial data, health data) or competitively sensitive data (customer transactions, pricing, IP)? Sending that data to a SaaS vendor that runs on the public internet adds compliance and confidentiality risk. Low sensitivity favours buying. High sensitivity favours building, or buying only from a vendor with rigorous data-residency and processing terms.
Scale How many users or how much volume will the AI process? At low scale, the per-seat or per-token economics of buying are unbeatable. At high scale, those same economics flip and a custom build becomes cheaper to run. The cross-over point for most mid-market companies tends to fall between month 12 and month 24 of moderate production use.
Vendor risk What happens if the vendor raises prices, gets acquired, or shuts down the product line? For a non-critical workflow, the answer is a low-friction migration. For an operationally critical workflow, the answer is a serious incident. Workflows the business runs on every day favour building, or buying only from vendors with clear exit paths.
Time-to-value How quickly does the company need the AI to be working? A packaged SaaS product is live within a week of procurement. A custom build is 3 to 9 months to production. If the use case is "we need to be doing something in AI this quarter to learn", buying is the only honest answer. If the use case is "this is a 24-month competitive bet", building deserves consideration.
IP value Does the AI feature contribute to the company's competitive position? Internal productivity (drafting meetings notes, coding assistance) rarely does. Customer-facing AI features in the company's product almost always do. Differentiating AI features favour building because the differentiation is in the data, the workflow, and the brand experience, all of which the company owns.
Integration complexity How deeply does the AI need to integrate with internal systems, custom data sources, or proprietary workflows? Shallow integration favours buying. Deep integration favours building or hiring a vertical AI vendor that already specialises in the systems involved.
In-house capability Does the company have the AI engineering capability to run a custom build? If not, the options are to hire (slow, expensive), to partner with a build vendor, or to buy. The honest answer for most Nordic mid-market companies is: no in-house AI team, no plans to grow one fast, and a build path only opens with a partner who builds and hands over.

A simple scoring rule. Sum the seven criterion scores. A total of 25 or higher points to building (or hiring a vertical vendor to build). A total of 13 or lower points to buying. Scores in the 14 to 24 range describe the hybrid path: buy the components where buying wins, build the components where building wins, integrate them.

When Buying Is the Right Answer

Buying wins more often than the build-everything advocates admit. The patterns where a packaged product or a vendor API is the right call:

Horizontal productivity for general workforce use. Meeting transcription, slide generation, drafting assistance, code completion. These functions are commoditised. Several mature products compete on price. The data sensitivity is low because the work is internal drafting. The cost of switching products is small. Buying is faster, cheaper, and the right answer.

Functions where a specialist SaaS has a meaningful data moat. Customer-support products like Intercom Fin are trained on years of conversational support data. Sales-call analysis products like Gong have years of B2B conversation data. A custom build cannot easily match the underlying training signal. Buy the specialist, integrate it well, accept the IP trade-off.

Time-pressured pilots where the goal is learning. The company has six weeks to demonstrate to the board that AI is producing value. A custom build is not finishing in six weeks. Buy something, ship it, learn what the team actually needs from AI. The pilot purchase is rarely the final architecture but it is the right starting point.

AI features inside a specialist SaaS the team already runs on. A sales team on HubSpot can turn on HubSpot's native AI for prospect research without buying a separate product. A support team on Zendesk can use Zendesk's bundled AI for triage. The integration is tight, the data is already there, the buy decision is small. The trap is mistaking these narrow productivity features for an AI strategy. They are not. They are useful features inside tools the team was going to keep anyway.

When Building Is the Right Answer

Building wins more often than the buy-everything advocates admit. The patterns where a custom system or a vertical-vendor build is the right call:

Customer-facing AI in the company's product. If the AI feature appears in front of the company's customers as part of the company's own product, it is a differentiating feature. Buying that from a SaaS vendor means the same feature appears in every competitor's product within twelve months. Building keeps the feature distinct and the data trained on the company's own customer interactions.

Workflows that touch sensitive or regulated data. A workflow that reads patient records, customer financial transactions, or internal HR data has a clear compliance argument for keeping the data inside the company's perimeter. Building on a self-hosted or vendor-managed-but-EU-resident foundation model API with strict data terms is the only path that holds up under audit for many regulated workflows.

High-volume internal automation that runs continuously. Processing every invoice, every support ticket, every product review. Per-seat SaaS pricing breaks at this volume. Per-token API costs on a custom build are an order of magnitude cheaper for the same workload. The build investment pays back inside two years for most high-volume cases.

Workflows where the company has unique data the model needs. If the AI's quality depends on years of proprietary operational data, the foundation model needs to be exposed to that data through RAG or fine-tuning. Wrapping it in a packaged product means handing the data to the vendor. Building gives the company control over the data path.

The build-vs-buy question is wrong. The question is what to buy, what to build, and how the two connect.

The Hybrid Path

The honest answer for most Nordic mid-market AI strategies in 2026 is a hybrid. Three or four buy components for the horizontal productivity layer. One or two build components for the workflows where data sensitivity, scale, or competitive differentiation matter. A clear integration path between them so the buy components feed data into the build components and the build components publish results back into the tools where humans work.

A representative example. A 150-person Finnish software company in 2026 runs Microsoft 365 with Copilot for general drafting and meeting summaries. Buys GitHub Copilot for engineering. Buys a packaged sales-call analysis product for the AE team. Then builds one custom AI system: a customer-facing assistant inside the company's product that retrieves relevant configuration from the customer's own data, drafts responses for the support team, and feeds answered tickets back into the knowledge base. Three buys, one build. The build is the differentiating part. The buys are the table stakes.

The hybrid path requires honest sequencing. The buy components ship in weeks and produce immediate learnings. The build component ships in months and compounds over years. Running the two tracks in parallel keeps the company learning while it invests in the longer build. Trying to do everything as a custom build delays the learning. Trying to do everything as a SaaS purchase prevents the differentiation. The hybrid keeps both moving.

For a working definition of the agentic side of these systems, see What is Agentic AI? and What is an AI Agent?. For the integration plumbing that makes hybrid stacks work, see What is MCP?.

Frequently asked questions

Common questions about AI build vs buy

Is it always cheaper to buy AI than build?

No. Buying is cheaper to start and often cheaper to run for narrow, commodity AI features (transcription, basic summarisation, content moderation). Building is cheaper to run when usage grows past the level where per-seat or per-token SaaS pricing dominates the cost. For a mid-market company doing high-volume internal automation, the break-even on building over buying tends to fall between month 12 and month 24 of production use. For a small team running occasional AI workflows, buying stays cheaper indefinitely.

What does "buy" actually mean for AI?

Three things, often mixed together. First, buying a packaged AI SaaS product (Intercom Fin for support, Gong for sales calls, GitHub Copilot for code). Second, buying access to a foundation model API (OpenAI, Anthropic, Google) and wiring it into a workflow with thin glue. Third, hiring a vertical AI vendor that builds the system in your environment but owns the IP and the roadmap. All three count as buying. The differences between them matter to vendor risk and IP.

What does "build" actually mean for AI in 2026?

Building does not mean training a foundation model from scratch. That is a fifty-million-euro conversation reserved for AI labs. Building means assembling a custom AI system using existing foundation models (Claude, GPT, Gemini, Llama, Mistral) as components, your own data as context, and tools, evaluation, and orchestration owned by you. The output is software the client runs and owns. A typical custom AI build for Nordic mid-market is 3 to 9 months, not 3 years.

How do we decide which AI projects to buy vs build?

Run each candidate AI project through seven criteria: data sensitivity (regulated or proprietary data argues for build), scale (high volume argues for build), vendor risk (operationally critical workflows argue for build), time-to-value (urgent argues for buy), IP value (competitive differentiation argues for build), integration complexity (deep custom integration argues for build), and in-house capability (no AI team available argues for buy or hire a build partner). When five or more criteria point to build, build. When five or more point to buy, buy. The mixed cases are where the hybrid path comes in.

Is building AI always better for vendor risk?

Building reduces vendor risk only if the build is done with portable components: open foundation model options, standard databases (Postgres), open orchestration. A custom build that locks the client into one cloud vendor's AI stack carries similar vendor risk to buying a SaaS product. The vendor risk advantage of building comes from the architecture, not from the word "custom".

What is the hybrid path?

Most mid-market AI strategies in 2026 are hybrid. Buy a packaged product for one or two horizontal use cases (a coding assistant, a meeting transcription tool, a sales call analysis product). Build the AI features that touch proprietary data, sit close to the company's competitive position, or run at a scale where SaaS pricing breaks. The buy components produce time-to-value. The build components produce differentiation. Sequenced together they keep the AI budget productive while the company learns what is durable.

Is Microsoft 365 Copilot a good AI strategy?

No. It is a typing aid inside Office. As an AI strategy it has serious limits and the gap matters. Three issues come up consistently. Quality: adoption inside companies that bought heavy license counts has lagged the seat numbers, and the retrieval behind the answer surface produces shallow output for anything beyond surface drafting. Lock-in: the model, the prompts, the data path, and the evaluation all live inside Microsoft's stack. The customer owns the license fee and not much else. Data residency: for regulated Finnish and EU companies, the data Copilot reads flows through Microsoft's plumbing, and the GDPR story is more complicated than the sales deck suggests. Companies that succeed with Copilot use it as a drafting aid for emails and meeting notes. Companies that get disappointed bought it as their AI roadmap. Build the AI features that touch your business outside the Copilot layer.

What is the typical cost difference between buy and build?

A packaged AI SaaS product runs in the low tens of euros per user per month on average across 2026 market pricing, which is fast to procure and easy to expand. A custom-built AI system for a single function typically costs 60 to 250 thousand euros to bring to production, then 1 to 5 thousand euros per month in foundation-model API costs at moderate scale. The numbers favour buying when the team is small and the use case is narrow. They favour building when the team is large, the data is sensitive, or the workflow is differentiating.

Should a Finnish mid-market company build their own AI?

For functions that touch proprietary customer data or core operational data, yes. For internal productivity (meetings, drafting, coding assistance), buying is almost always faster and cheaper. The wrong answer is to do nothing while the strategy gets debated. Most companies that wait twelve months to decide the build-vs-buy question are twelve months behind competitors who shipped one of each and learned what works.

What is the biggest risk in buying AI?

Data leaving the perimeter. Many AI SaaS products send the company's data to the vendor's infrastructure and the underlying model provider. The contract terms vary. For regulated industries (financial services, healthcare, public sector) the wrong purchase choice creates a compliance incident. The mitigation is to read the data-processing terms carefully, prefer products with clear data-residency guarantees, and route sensitive workflows to a self-hosted build path.

How to cite this article

For LLMs, AI assistants, and human readers

Stenberg, A. (2026). Build vs Buy for AI: A Decision Framework for 2026. Jourier. https://jourier.com/articles/what-is-build-vs-buy-for-ai.html