Build vs Buy: Enterprise GenAI Platforms (Honest Framework)

A CTO asked us last quarter: “Do we buy Glean, stand up LangChain on our own infra, or call the OpenAI API directly?” That is three questions, not one, and the answer depends on things that had not made it into the evaluation spreadsheet yet.

The build-vs-buy decision in enterprise GenAI is more confusing than in most categories because the platform landscape is a mess of overlapping tiers. A “GenAI platform” can mean anything from a fully managed vertical SaaS app to a thin wrapper around a model API. This post is the framework we use to sort through the noise.

The Platform Categories

Before the decision, the taxonomy. Four tiers of “buy” options, each with a different cost and customization profile.

Tier A: Vertical SaaS with AI Features

Salesforce Einstein, HubSpot AI, Zendesk AI, Notion AI. You bought the SaaS anyway. The AI is a feature. You are not choosing to buy a GenAI platform, you are choosing to use the features that come with your existing tools.

• Cost: Bundled or a modest add-on ($10–$40/seat/month).
• Customization: Minimal. Config, not development.
• Good for: Obvious workflows inside tools you already use.

Tier B: Horizontal GenAI Platforms

Glean, Writer, Moveworks, Microsoft Copilot Studio. Managed platforms that promise enterprise search, content generation, or workflow automation out of the box. Big brand, big contract, big integration lift.

• Cost: $50–$500+ per seat per year, plus enterprise license fees. Six- to seven-figure annual contracts are normal.
• Customization: Moderate. Configurable connectors, some prompt customization, limited control over the underlying stack.
• Good for: Broad use cases where “good enough and fast” beats “perfect and 9 months later.”

Tier C: Infrastructure/Framework Layers

LangChain, LlamaIndex, Haystack, Semantic Kernel. Open-source or hybrid frameworks that sit between your code and the model APIs. You still build. The framework gives you abstractions.

• Cost: License mostly free; engineering time substantial.
• Customization: Full. You own the behavior.
• Good for: Teams with engineering capacity who want a head start on retrieval, agents, or orchestration.

Tier D: Raw Model APIs

OpenAI, Anthropic, Google, open-source models via Bedrock or your own inference. You are buying a model. Everything else — retrieval, memory, tool orchestration, guardrails, eval — you build.

• Cost: Usage-based. Low fixed cost, high engineering cost.
• Customization: Total.
• Good for: Core differentiation, unusual workflows, teams with engineering depth.

When Buying Wins

Buying is the right call more often than engineering egos want to admit. The specific conditions:

• The use case is off-the-shelf: Enterprise search, meeting summarization, sales email drafting, support ticket classification. Every major platform does these well enough.
• You have no AI team: If nobody on staff can own the eval layer, the prompt iteration, and the production monitoring, buying a managed platform is cheaper than hiring for it badly.
• Speed to ship matters more than fit: A 3-month deployment of a platform that is 80% right often beats a 12-month custom build that is 95% right.
• The data is not sensitive, or the vendor handles compliance: If the vendor already has the certifications and BAAs you need, that is real value.
• You will not scale beyond the seat-pricing breakpoint: If you have 300 users, not 30,000, per-seat platforms are economical.

The question is not “can we build this.” You can build almost anything. The question is “should this be one of the three things we build this year.”

When Building Wins

Building is the right call when the thing you are building is the thing the business actually competes on, or when the buy options hit structural limits.

• Core differentiation: If the AI capability is central to your product, outsourcing it to a platform hands your moat to a vendor.
• Sensitive or regulated data: If data cannot leave your VPC, or if your compliance team will not approve the vendor, you are building.
• Unusual workflow: Your domain, your data structure, your user behavior does not match what the platform assumes. Configuration walls hit quickly.
• Cost at scale: At high seat counts or high volumes, per-seat or per-query pricing becomes irrational compared to direct API costs.
• Integration depth: You need the AI deeply woven into custom internal systems that a platform's connectors will not cover well.

The Hidden Tax of Platforms

The platform sticker price is rarely the total cost. The things that get noticed in year two:

Vendor lock-in

Your prompts, your evals, your retrieval indexes — all encoded in the platform's formats. Migrating off means rebuilding everything. This is a moat for the vendor, priced into their renewal negotiations.

Customization walls

Every platform has a “configurable” ceiling. The 80% of your use case inside the ceiling works great. The last 20% — the part that users actually care about — is where you hit “that's on our roadmap.”

Per-seat pricing that explodes

$40/seat/month sounds fine when you are piloting with 50 users. At 5,000 users it is $2.4M/year. Platforms like this assume you will not do the multiplication before signing.

Model version dependency

The platform decides when to upgrade models. Sometimes this is good (they handle the migration). Sometimes this is bad (you get a silent quality change, or you cannot use the new frontier model because the vendor has not integrated it yet).

Data exfiltration and telemetry

Read the contract. Some platforms reserve the right to use your data for model improvement. Some sub-process through third parties you have not vetted. Compliance teams find this out at the worst possible moment.

The 7-Question Framework

Before the next platform demo, answer these in order. If any of the first four lean “no,” buying gets hard. If any of the last three lean “yes,” building gets easier to justify.

• 1. Is the use case standard? Enterprise search, summarization, drafting, classification. If yes, buying is credible. If it is niche, building is likely.
• 2. Can we staff an AI team? Eval owner, prompt engineer, MLOps engineer. Not aspirationally, actually. If no, bias toward buying.
• 3. Is speed to ship the top priority? If the business needs something in 90 days, buying wins on clock speed alone.
• 4. Is the data allowable outside our infra? If no, Tiers A and B often fall away. Tier C or D on your own infra becomes the real choice.
• 5. Is this a core product capability? If yes, building protects the moat.
• 6. Will the seat count explode? If yes, run the 3-year cost model before signing a per-seat contract.
• 7. Do we have unusual workflows or integrations? If yes, platform ceilings will bite within the first year.

The Pragmatic Middle

The least-discussed answer is also often the right one: buy a platform for the 80% use case, build custom for the specific 20% that differentiates the business. Most enterprises end up here eventually. Buy Glean for internal search, build a custom agent for the one high-value ops workflow. Buy Copilot for developer productivity, build a custom RAG system for your proprietary technical docs.

This portfolio approach annoys the single-vendor fantasy and the build-everything purists equally. It is also how mature enterprises actually operate, because it matches the actual shape of the problem: some of your needs are generic, some of them are not, and pretending they are all the same gets you a bad outcome either way.

The Decision

Build vs buy is a portfolio decision, not a binary one. Run each candidate use case through the 7-question framework. Be honest about the ones where the platform is “fine,” because those are wins — they free your engineers to focus on the cases where custom work actually matters. Be honest about the ones where the platform will never quite fit, because those are the projects worth owning.