Should you build your own internal copilot? Usually not yet.
The buy case is stronger than engineers admit and the build case is stronger than vendors admit. A decision that comes down to where your leverage lives.
Somewhere right now an engineering team is building an internal chat assistant that a vendor sells for eleven dollars a seat, and a procurement team is buying a platform to do what four API calls would have done. Both rooms are certain. Neither has done the math. Let me offer the version I draw on whiteboards.
Buy the commodity layer. Coding assistants, meeting summarizers, general chat with your documents wired in: these are products now, with security reviews other people already paid for. The build version of a coding assistant is not a weekend of API calls; it is an evals harness, IDE plugins, model routing, and a roadmap you now own forever. Unless developer tooling is your product, rent it.
Build where your leverage is your data and your workflow. The assistant that drafts responses inside your claims process, speaks your policy manual, and writes into your systems of record is not on anyone's price list. This is retrieval plus well-designed tool access on top of rented models, and the unit economics are honest: current API pricing (published per token, with caching discounts that reward exactly this shape of workload) makes the marginal cost of a bespoke assistant a rounding error next to the engineering time. The engineering time is the real bill; spend it only where the workflow is genuinely yours.
The questions that sort any specific case. When a room is stuck, I ask four things and the answer usually falls out. Does the tool touch a workflow a competitor could not copy by buying the same vendor? If no, buy. Would the vendor's roadmap serve you even if your feature requests are ignored, which they will be? If yes, buy. Do you have an engineer who wants to own this in year three, not just build it in quarter one? If no, buy, whatever the spreadsheet says. And can you write down, today, the eval that would prove the built version works? If no, you are not ready to build anything, and the honest next step is the eval, not the assistant.
The two failure stories, so you can recognize yours early. The build failure is a beautiful assistant that answered last year's workflow: the process changed, the team that built it moved on, and now the maintenance conversation happens in the budget meeting, where these conversations go to be lost. The buy failure is quieter: eleven dollars a seat times four thousand seats times three vendors whose features converged, plus renewal terms that assume nobody is counting. One tends to end in a writedown, the other in a subscription audit. (I have sat in both meetings. The writedown meeting has better attendance.)
What the audit adds. In readiness audits, this whole decision usually collapses once two numbers exist: what the workflow costs today in hours, and what the commodity tools already deployed are actually used for. Most companies discover they are underusing what they bought and overspecifying what they want to build. Fix those two and the build list gets short enough to staff properly, which was the goal all along.
A word about the room's politics, because the math is rarely what decides. The build camp is usually engineering, arguing for the version that grows their skills, and there is nothing cynical in that; it is what good engineers do. The buy camp is usually finance or IT, arguing for the version with a contract to point at when something breaks. Both camps present their preference as analysis. The way through is to make the decision criteria public before anyone runs numbers: what we buy, what we build, and who owns each in three years. Criteria agreed in the abstract survive contact with the specific vendor demo. Criteria invented afterward are a press release for a decision already made, and everyone in the room knows it, politely.
The maintenance number nobody writes down. Whatever the build estimate says, add the standing cost: model API changes, prompt drift as the underlying models update, the eval suite that has to rerun when anything moves, and the person who answers "why did the assistant say that" at odd hours. Across engagements the honest figure lands around a fifth to a third of an engineer, permanently, per built assistant. Cheap for the workflow that defines the business. Absurd for the meeting summarizer.
The hybrid that usually wins. Bought copilots for the commodity 80 percent, one built assistant for the workflow that defines your business, and a firm rule against building anything a vendor demo can replicate in an afternoon. The drama mostly comes from teams arguing about the first category while the second sits unstaffed. Reverse the attention and the argument dissolves.