Custom AI vs Off-the-Shelf — A Decision Framework

The build vs buy question, framed for AI

The build-vs-buy decision in enterprise software has been studied for fifty years, but the rise of foundation models has changed the underlying economics enough that the old heuristics no longer fully apply. The question is no longer binary — and the costs that matter are no longer just upfront engineering effort versus per-seat licensing.

The frontier model providers (Anthropic, OpenAI, Google) sit at the bottom of the AI stack. SaaS application vendors (Salesforce Einstein, HubSpot, Notion AI, etc.) sit at the top. The interesting question for most businesses is no longer "build or buy?" — it's "where on the stack should we commit, and which layers should we own?"

The modern AI stack

Almost no business in 2026 should build at Layer 0 or Layer 1 — the capital intensity is prohibitive and the marginal performance gain over frontier APIs is negative. The interesting choice points are at Layers 2 through 5, and the right answer is typically a mix: own the layers that create competitive advantage, buy the layers that don't.

The "buy" case — where off-the-shelf wins

Off-the-shelf AI features inside existing SaaS products — Salesforce Einstein, HubSpot AI, Microsoft Copilot, Notion AI, Zendesk AI, Intercom Fin — have improved substantially over 2024–2026. They are typically the right choice when:

• The workflow is generic and well-understood. Drafting an email, summarising a meeting, classifying a support ticket. These are commodity tasks; the SaaS vendor solves them well and the cost of building bespoke is unjustifiable.
• Your team already lives in the host product. If your CRM is Salesforce and your sales team is in it 8 hours a day, an AI capability inside Salesforce has zero adoption friction. A separate tool, however better, has substantial.
• Speed-to-value matters more than long-term flexibility. A switch on, tomorrow, that captures 60 percent of the available value is often more valuable than a six-month bespoke build that captures 90 percent.
• The volume is bounded. Off-the-shelf seat-based pricing is rational at small scale and becomes irrational at large scale. The crossover point depends on the product.

The "build" case — where custom wins

Custom AI implementations — built around your specific workflows, on your own infrastructure, using foundation model APIs directly — are typically the right choice when:

• The workflow is competitively differentiating. If how you handle this task is part of why customers choose you, you don't want a competitor buying the same off-the-shelf capability and copying you in a week.
• Your data is structurally messy or specific. Off-the-shelf AI works against generic data shapes. Industry-specific document formats, legacy systems, custom data models — these require custom builds.
• Compliance or data residency rules the architecture. Healthcare, legal, government, financial services — the data residency and audit requirements often rule out SaaS AI features that move data to vendor cloud. See finance and medical for sector-specific patterns.
• You need to integrate across many systems. If the workflow spans 6+ systems, a custom orchestration layer is usually more durable than chaining together AI features from multiple SaaS products.
• The volume is high enough that seat-based pricing becomes punitive. Custom builds have higher upfront cost and lower marginal cost; SaaS has the inverse profile. At scale, the crossover heavily favours custom.

"The dominant enterprise pattern emerging through 2025 is the hybrid stack — foundation model APIs at the bottom, custom orchestration in the middle, and a mix of SaaS and custom interfaces at the top." — Andreessen Horowitz, Enterprise GenAI Spend Report (2024)

The hybrid pattern most businesses actually use

In practice, very few real production environments are pure-build or pure-buy. The dominant architecture in 2026 is hybrid by layer:

The vendor lock-in question

The McKinsey 2024 survey found that 73 percent of enterprises cite vendor lock-in as a top concern in generative AI procurement. The risk is real but often misunderstood. Lock-in to a frontier model provider (Anthropic, OpenAI) is largely manageable through portable code — open-source abstractions standardise the call interface across providers, and migrating between Claude and GPT for a well-architected system is typically a days-of-work problem, not months.

Lock-in to a SaaS AI feature is structurally harder to escape. The vendor controls the data, the prompts, the model selection, and the integration interface. When the SaaS vendor raises prices, deprecates a feature, or is acquired and rebuilt, your team has limited recourse. This is the dimension of lock-in worth pricing into long-term planning.

Decision framework

A pragmatic framework distilled from observed deployments:

1. Start by listing the AI capability you need. Not "add AI to our CRM" — specifically, "draft cold outreach emails personalised to each prospect's last LinkedIn post and our prior conversation history."
2. Check whether your existing SaaS already does it well. Don't build what your existing tools can deliver acceptably. Switch on the feature, measure for 30 days, and only build if the result is materially short of what's needed.
3. If building, decide which layers you own. Foundation model: API. Retrieval: your infrastructure. Orchestration: usually custom for complex workflows. Interface: where your users already are.
4. Architect for model portability from day one. Use open-source abstractions, write evaluations that don't depend on any specific model's quirks, version your prompts.
5. Measure total cost of ownership, not just licence cost. Off-the-shelf has lower upfront and higher ongoing. Custom has the inverse. How we work documents how we approach this trade-off in practice. The crossover for any given workload is usually predictable.

Common build-vs-buy traps

• Building because "the demo was easy". Demos are 10 percent of the work. The other 90 percent is observability, retries, evals, edge cases, and integration.
• Buying because "it's faster", then needing to migrate later. Off-the-shelf adopted to capture quick wins often becomes infrastructure debt when the workflow grows beyond what the SaaS supports.
• Building inside a single vendor's ecosystem and calling it custom. If your "custom" build runs entirely inside one SaaS platform's AI runtime, you have all the operational obligations of custom and most of the lock-in of SaaS.
• Underestimating change management for off-the-shelf. AI features inside SaaS products require user training, prompt configuration, and ongoing tuning — they are not zero-effort wins.

Where to go from here

For most workflows, the most useful first step is to test what your existing SaaS tools already provide — measured against a clear definition of success — before deciding whether to build. Our AI consulting service covers this evaluation upstream of any build decision, and custom AI solutions for when off-the-shelf has been ruled out for substantive reasons.