Buy or build is the question every internal-copilot initiative starts with, and it usually gets a political answer: IT wants to buy, the data team wants to build, and the decision goes to whoever argued last. Since we sell engineering, you might expect us to say “build”. We won’t. Building the wrong copilot is a more expensive mistake than buying the wrong one, so here is the framework we actually use — including the cases where the honest advice is to get your credit card out.
Buy when the workflow is generic and the data is simple
If your workflow looks like everyone else’s workflow, a vendor has already built it better than your first version will be. Drafting emails and documents, summarising meetings, general coding assistance, Q&A over a public or non-sensitive corpus — these are commodity problems, and commodity problems deserve commodity prices.
The “data is simple” half matters as much as the “workflow is generic” half. Buying works when the copilot’s knowledge either ships with the product or lives in one well-behaved source with permissions flat enough that everyone may see everything it indexes. If you can write the access rule in one sentence, buy. A bought copilot on simple data is live in weeks and someone else patches it — that is genuinely hard to beat, and pretending otherwise is how engineering teams end up rebuilding a chat UI for a year.
Build when permissions, domain data or audit requirements dominate
The calculus flips when the hard part is not the model but everything around it.
- Permissions — When the copilot must respect who may see which contract, case file or salary band, across several source systems, at query time, a generic connector will not model your access reality. Permission-aware retrieval is bespoke work by nature — it is usually the single biggest effort in taking RAG to production, and it is precisely the part vendors gloss over in the demo.
- Domain data — When correct answers depend on your pricing logic, your contract history, your machine documentation — knowledge that exists nowhere else — the copilot’s value is exactly the part no vendor can ship. Generic answers over proprietary questions are worse than no copilot, because people trust them once.
- Audit requirements — When a regulator or auditor will ask “who approved this action and what did the system know”, you need citations, approval gates and an audit trail per action, designed in from the start. Bolting audit onto a bought product means waiting on someone else’s roadmap for your compliance posture.
One of these three dominating is a build signal. Two or more and the decision has made itself.
The hidden cost is the same either way
Here is what both camps underestimate: integration and evaluation are the real cost, and you pay them in both scenarios. A bought copilot still has to be wired into your identity provider, your source systems and the tools where work actually happens — a copilot in a separate tab dies in that tab. And bought or built, you still need your own eval suite: a golden dataset of your questions, adjudicated by your domain owners, run against every change. Vendors update their products on their schedule, not yours; without your own regression evals, every vendor release is an uncontrolled experiment on your staff. “Buy” was never “no engineering”. It is less engineering, aimed at the same two problems.
The hybrid that usually wins
In practice the strongest pattern is not a clean buy or a clean build. Buy the model — frontier models are a commodity you rent, and building your own is almost never the answer. Own the layer around it: your retrieval over your corpus, your permission enforcement, your eval suites, your audit trail, your prompts, all versioned in your repos. That is our model-agnostic, data-jealous stance applied to copilots: hold the model loosely, because your evals make swapping it an afternoon’s decision; hold the data layer tightly, because it is where every durable advantage and every compliance obligation lives. Companies that get this backwards — loyal to a model vendor, careless with the retrieval and eval layer — end up owning the one thing that depreciates and renting the one thing that compounds.
If you are weighing this decision for a real workflow, our Applied AI & Automation practice will walk the framework with you honestly — including telling you to buy, when buying is right. A technical call, not a sales call.