build, buy, or embed: evaluating AI vendors

A mid-size customer support SaaS company spent 14 months and roughly $2 million building an in-house AI ticket classifier. By the time it shipped, OpenAI and Anthropic's off-the-shelf APIs matched its accuracy at a fraction of the cost. The team hadn't built a moatmoatA lasting edge over competitors: a resource, capability or position they cannot easily replicate, letting a firm earn above-average returns over time.View full definition →. They'd built a museum piece.

This scenario repeats across the SaaS sector every quarter. The decision isn't ideological (build good, buy bad). It's a cost, control, and speed tradeoff that changes based on what the AI feature actually does for your product.

The three paths

Build: Develop the AI capability in-house, usually by fine-tuningfine-tuningFine-tuning adapts a pre-trained model to a specific task or domain by continuing training on a smaller, targeted dataset, improving accuracy and style for that use case.View full definition → open-weight models (models like Meta's Llama or Mistral whose weights, the learned parameters, are publicly downloadable) or training custom models on proprietary data.

Buy: Purchase a point solution, a vendor product built for one specific job (a fraud-detection tool, a résumé screener, a call-transcription engine).

Embed: Call a foundation model APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → (a general-purpose large language modellarge language modelA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → accessed over the internet, like GPT-4o, Claude, or Gemini) and wrap your own product logic and interface around it.

Most SaaS companies in 2026 use all three simultaneously, for different features. The skill is matching the right path to the right use case.

Scoring the tradeoffs

Total cost

Building looks cheap on a slide (just engineer salaries) but hides costs: data labeling, GPU/cloud compute, ongoing retraining, and the opportunity cost of your best engineers not shipping core product. A believable range for a custom model with real production reliability: several hundred thousand to a few million dollars in the first year, before maintenance.

Buying has a visible, predictable cost: a subscription or usage fee. Vendors like Intercom (Fin), Zendesk, or specialized fraud-detection players (e.g., Sift) price per seat or per resolution. Easy to budget, harder to customize.

EmbeddingEmbeddingAn embedding is a numerical vector that represents data (text, images, or items) in a way that captures meaning, so similar items sit close together in space.View full definition → costs scale with usage. As of early 2026, OpenAI and Anthropic API pricing runs in the range of a few dollars to a few tens of dollars per million tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → depending on model tier (this is a rough, publicly listed estimate and changes frequently, check OpenAI's pricing page for current rates). Costs are variable but low fixed overhead. A startup can prototype for under $500.

Worked example: A SaaS company adds an AI summarization feature to 10,000 customer calls per month, averaging 1,500 tokens of output each.

• 10,000 calls × 1,500 tokens = 15,000,000 tokens/month
• At an illustrative rate of $10 per million output tokens: 15 × $10 = $150/month
• Compare to a point-solution vendor charging $0.50 per call: 10,000 × $0.50 = $5,000/month
• Compare to build: one ML engineer at ~$180,000/year fully loaded, plus compute, easily exceeds $20,000/month amortized in year one.

Embedding wins on pure cost here, unless call volume grows 100x, at which point the API bill scales linearly and buy or build economics change.

Lock-in

Lock-in is the degree to which switching providers later is expensive or slow. It comes in three flavors:

• Data lock-in: your proprietary data lives in a vendor's system and extracting or reusing it is hard.
• Workflow lock-in: your team's processes are built around one tool's UI and quirks.
• Model lock-in: your prompts, fine-tuning, and evaluation harness are tuned to one model's specific behavior.

Buying a point solution usually means the deepest lock-in: switching fraud-detection vendors means re-integrating APIs, retraining staff, and often losing historical model tuning.

Embedding foundation models has moderate lock-in. Providers increasingly support portable formats, and open-weight alternatives (Llama, Mistral, Qwen) let you self-host if a vendor's price or policy changes. But prompt engineeringprompt engineeringPrompt engineering is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.View full definition → and evaluation pipelines are rarely fully portable across model families without rework.

Building has the least vendor lock-in but the most internal lock-in: your own team's undocumented decisions become the dependency.

Time-to-value

Embedding is fastest. A working prototype using GPT or Claude APIs can ship in days. This is why nearly every SaaS AI feature announced in 2023 to 2026 started as an embedded API call.

Buying is fast if the vendor's use case matches yours closely; slow if you need heavy customization (integration, security review, procurement can take months in enterprise contexts).

Building is slowest almost always. Even simple custom models require data collection, labeling, training, evaluation, and safety testing before shipping.

A decision framework

Ask three questions before choosing:

1. Is this capability core to your competitive advantage? If AI *is* your product (e.g., an AI coding assistant), building or deep customization is likely justified. If AI is a feature bolted onto an existing workflow tool (e.g., auto-summarizing tickets in a CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.View full definition →), embed or buy.

1. Is the underlying task commoditized? Text summarization, translation, and basic classification are now commodity capabilities across foundation model providers. Building here rarely pays off. Highly domain-specific tasks (say, parsing niche legal contracts with proprietary taxonomy) may justify fine-tuning or a specialized point solution.

1. What's your realistic usage volume and growth curve? Low volume favors embedding (near-zero fixed cost). Very high, stable volume can flip the math toward building or self-hosting an open-weight model, since API costs scale linearly forever while infrastructure costs can flatten.

A simple gut check used by several SaaS product leaders: if you could not defend, in one sentence, why this AI capability needs to be proprietary, default to embed.

Evaluation checklist for any vendor or API

Before signing anything, SaaS buyers should push vendors on:

• Benchmarks on your data, not theirs. Public benchmarks (like those tracked on Stanford's HELM) show general capability, not performance on your specific documents or customer language.
• Data handling and residency. Where does your data go? Is it used for further model training? For EU customers, does the vendor support GDPR (General Data Protection Regulation) requirements around data processing agreements?
• Latency and uptime SLAs (Service Level Agreements, contractual guarantees on response time and availability).
• Exit plan. Can you export your fine-tuning data, prompts, and logs if you leave?
• Regulatory exposure. Under the EU AI Act (in phased effect 2025 to 2027), certain "high-risk" AI use cases (e.g., credit scoring, employment screening) carry documentation and transparency obligations that fall partly on the deploying company, not just the model vendor. If you're buying or embedding AI into a regulated workflow, ask who owns compliance.

A quick technical illustration

Here's what "embedding" actually looks like in practice, a few lines calling a foundation model API to classify support tickets:

from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Classify ticket urgency: low, medium, high."},
        {"role": "user", "content": ticket_text}
    ]
)
print(response.choices[0].message.content)

This is the entire "AI feature" for many SaaS products in their first shipped version. The build decision only becomes relevant later, if accuracy, cost at scale, or data privacy demands force a move to fine-tuning or self-hosting.

Key Takeaways

• Match the path to the use case, not to trend. Commodity tasks (summarization, classification) favor embedding; core differentiators may justify building; narrow regulated tasks may favor a specialized point solution.
• Cost comparisons must include hidden costs. Building hides engineering time and maintenance; buying hides customization limits; embedding hides long-run scaling costs.
• Lock-in is not binary. Score it across data, workflow, and model dimensions separately before signing a contract.
• Speed favors embedding almost always. Use it to validate demand before committing to a heavier build or buy investment.
• Compliance obligations (EU AI Act, GDPR) often stay with the deploying SaaS company, regardless of which path you choose, so vendor contracts should specify who owns what documentation.