Build vs. Buy Conversational AI: What the Build Case Always Leaves Out

A scene from last quarter

A CFO at a North American insurer slid a build business case across the table and said, "My engineering leader thinks we can do this for forty percent less than your contract. Tell me where he is wrong." The case was good. The slide on the front was a sober month-one estimate, two engineers, an API key, a prototype by quarter end. The slide that decided the question was three pages back. Year-two run-rate engineering. It was empty.

Every build case I read starts the same way. The cheap slide is at the front. The expensive slide is at the back, and it is usually a placeholder. The job of a serious CFO is not to reject the build case. It is to make the back slide as well-staffed as the front.

What is actually being compared

Build and buy are not opposites. Every production deployment of conversational AI is part build, part buy. The model is rented. The integrations, the prompts, the policies and the evals are built. The platform sits in the middle, and that middle layer is the only real decision.

Five layers, one budget each.

The model. GPT, Claude, Gemini, an open weights model on your own infrastructure, or a routing layer that switches between them. Even the most ambitious build teams rent this.

The platform. Orchestration, retrieval, tool calling, conversation memory, evaluation, observability, guardrails, channel adapters, handoff, audit log. This is the layer the build case under-estimates. Always.

The integrations. Your CRM, ticketing, knowledge stores, identity, payments, custom systems. Same work in both paths. The pricing changes.

The content. Knowledge ingestion, prompt engineering, policy authoring, ongoing curation. Same work in both paths. The tooling changes.

The operating team. Whoever runs this on day ninety, day three hundred and sixty-five, and day one thousand. Same headcount question. Different skills profile.

The build path absorbs layers two through five in-house. The buy path licenses layer two and runs three through five with vendor support. Layer one is rented either way. If your build case does not separate these five lines, it is not finished.

The slide the build case always leaves out

Year-two run-rate engineering. The build path needs a permanent platform team. Not the original build team, the team that comes after them. Model providers change their APIs. Evaluation sets drift. Security review cycles every quarter. Compliance asks for an audit log feature that was not in the original spec. New channels show up. Your retrieval quality regresses and nobody knows why.

I have never seen a build case where year-two run-rate engineering came in below sixty percent of year zero. Most come in closer to seventy-five. Multiply that by three years and the model API line on the front slide stops mattering. The slide that decides the question is the one that takes the original team's headcount and asks, "How many of these people are still here in 2028."

The three lines that hide inside year one

Beyond run-rate, three categories that almost never appear in the first draft.

Evaluation tooling. You cannot improve a model you cannot measure. Production-grade conversational AI needs offline evals, online evals, regression tests on every prompt change, human review workflows, and dashboards your CX leaders can actually read. Buying this is a six-figure item on most platforms. Building it is a multi-quarter project that ships before anything customer-facing does.

Guardrails and safety. Prompt injection. PII redaction. Jailbreak resistance. Brand-tone enforcement. Refusal handling. Each is solvable. Together they are an engineering team's quarter.

Channel adapters. Web, WhatsApp, Messenger, SMS, email, voice. Each channel has its own session model, message format, attachment handling and idempotency rules. None of them are interesting to build. All of them have to be built before a customer can use the assistant.

If a build business case has a single line item called "platform engineering," that line is wrong. The correct version has fifteen line items, and seven of them are larger than anyone wanted them to be.

Opportunity cost is a real number

Here is the line that decides more build versus buy cases than any other, and the one finance teams are most often forced to add by the CFO rather than the engineering leader.

Every quarter spent building infrastructure is a quarter not spent shipping use cases. If your buy-path competitor reaches measurable ROI in quarter two and you reach it in quarter six, the four-quarter delta is real revenue, real cost displacement, real customer experience. Price it. The number is rarely small.

I have watched enterprises win the build versus buy debate on cost and lose the same year on opportunity. The finance case was correct on its own terms. The business case was not.

When building actually wins

I am not going to pretend the answer is always buy. Three cases I have seen the math flip.

The assistant is the product. If you sell AI as your differentiated offering to customers, the platform is your IP. Buying it is buying your competitor's roadmap. This is the only case where the build path is obvious from the first slide.

No licensed platform meets a constraint you cannot work around. A regulator, a sovereignty requirement, a customer contract clause. Real constraints, not preferred ones. Test the constraint with three vendors before declaring it binding. Most of the constraints I hear in this category dissolve under a procurement lawyer's second pass.

An existing ML platform team with capacity. Some enterprises already run a mature ML platform with evaluation, observability and security tooling in place. Adding a conversational layer is incremental, not foundational. The cost model is genuinely different and sometimes the build path wins on its own merits.

If none of these three apply, the build case usually rests on the engineering team's preference. That is not an illegitimate preference. It is just not a finance argument.

The hybrid path nobody puts in the deck

Most enterprises end here, and most of them did not plan to. License the platform that handles the heavy infrastructure. Build the differentiators on top. The retrieval over your unique data. The policies that encode your specific risk posture. The custom tools that touch your one-of-a-kind systems. The workflows nobody else has. The platform is the chassis. Your team builds the body.

This is only honest if the platform you license respects it. Demand five things at contract signing. Model choice, with the ability to switch model providers without a rebuild. Custom tools, exposed through a protocol you can write against. Prompt portability, so your year-two work is yours. MCP support, or a credible plan inside a quarter. Full export of your conversation data and your retrieval index, on demand, in a format you can use elsewhere. If a vendor pushes back on any of these, the contract is not done.

Six questions a CFO should ask before signing either path

I would ask my engineering leader these in order, and refuse the decision until all six have numbers attached.

If any of the six comes back without a number, the decision is not ready for the board.

The honest version

I sell a platform. I am not a neutral party on this question. The reason I am still confident the buy path wins in most cases is the same reason I am confident the build path wins in the three cases above. The honest comparison favours whichever side has the better answer to the operating team question on day three hundred and sixty-five. Most enterprises I work with cannot staff that team for the build path and can staff it easily for the buy path. The math follows.

If you want me to pressure-test your build case against the buy case in writing, book a working session. I will fill in our numbers honestly, including the cases where the build path is the right answer. The strongest decisions go to the board with both columns filled in by people who actually have to deliver them.