Build, Buy, or Wrap? A Decision Framework for Enterprise AI
The Same Meeting, Every Time
The setting changes; the meeting doesn't. A team needs an AI capability, say, drafting responses to customer complaints. The CTO sketches an in-house system on the whiteboard: full control, our data, our rules. The operations lead has a vendor demo lined up for Thursday: proven product, live in four weeks. And halfway through the discussion it emerges that an analyst in the team already built the thing, sort of, by wrapping a foundation model with a clever prompt and a spreadsheet, and people have quietly been using it for a month.
All three of them are right, for different problems. The expensive mistake is treating this as a matter of taste, or of who argues loudest. It is a portfolio decision with a structure, and the structure is worth making explicit, because you will face this meeting not once but every quarter for the foreseeable future.
The Three Options, Defined Honestly
Buy means a SaaS product with the AI already inside: the recruitment screening tool, the contract analysis platform, the customer service suite with a copilot bolted on. You get speed and someone else's R&D budget. You also get their roadmap, their pricing model, and their data processing terms.
Wrap means putting a thin layer of your own around a foundation model API: your prompts, your retrieval over your documents, your integration into the workflow. The model does the heavy lifting; you own the orchestration. This is what most "we built an AI tool" stories actually describe.
Build means owning the stack more deeply: fine-tuned models, your own evaluation infrastructure, your own serving and monitoring. Worth saying plainly: almost nobody should be training models from scratch, and "build" in 2026 nearly always means a heavyweight version of wrapping. Build and wrap sit on a spectrum of ownership rather than across a hard line. The question is how far down the stack your ownership goes.
Four Questions That Decide It
When we work through this with clients, four questions do nearly all of the deciding. They are worth asking in order, because the early ones eliminate options cheaply.
1. Is this capability differentiating, or commodity?
Meeting transcription is a commodity. Expense categorisation is a commodity. Nobody chooses your firm because your internal meeting notes are better summarised. For commodity capabilities, buying is almost always right: the vendor amortises development across thousands of customers, and your engineers stay focused on things customers pay you for.
The calculus flips when the capability touches whatever your margin actually depends on: your underwriting judgment, your deal screening, your pricing logic. Handing that to a vendor means feeding your most valuable data patterns into a product your competitors can also subscribe to. Differentiating capabilities justify ownership. Most capabilities, if you are honest, are not differentiating.
2. Where does the workflow live?
If the work happens inside Salesforce, SAP, or your case management system, an embedded option that meets people where they already are will beat a better tool that lives in another tab. We have watched objectively superior standalone tools lose to mediocre embedded ones, repeatedly, for the simple reason that adoption is a workflow problem before it is a technology problem. Integration gravity is real. Respect it.
3. How fast is the underlying capability moving?
Here is the question most frameworks miss. The model layer is improving on a cadence of months, with new tiers appearing above what was previously the top. That cadence punishes heavy builds: whatever you spend a year constructing is depreciating against a baseline that improves while you sleep. More than one company has finished an eighteen-month custom build only to find its core function available off the shelf for $30 a seat.
Thin wraps invert this. Because they sit lightly on the model layer, they inherit every upgrade for free; swap the model string, re-run the evals, done. The faster the underlying capability moves, the lighter your construction should be. Build heavy only where the model layer is not the part that matters: your data plumbing, your domain logic, your integrations. Those appreciate. Model-adjacent cleverness does not.
4. Who runs it in year two?
Every option has a year-two bill, and it is the question that disqualifies the most candidates. Prompts drift as models get updated. Vendors deprecate the API version you built against. The person who built the wrapper changes jobs. If you cannot name the individual, not the committee, who will own the system's quality, cost, and incidents in eighteen months, you have no business building or wrapping. Buy, and make the maintenance someone else's problem by contract.
The Hidden Bill for Each Option
The sticker prices mislead in all three directions, so it is worth knowing where each option hides its costs.
Buying hides its costs in scale and dependency. Per-seat pricing that looked reasonable at fifty users becomes startling at five thousand, especially once you notice that the $40-per-seat tool is, underneath, perhaps a dollar's worth of model API calls and a nice interface. You pay the vendor's margin on every token forever. Add the data processing agreement you signed in week one and renegotiate in year three, and the dependency on a roadmap you do not control.
Wrapping hides its costs behind the demo. The weekend prototype is real, and so is the gap between it and a system colleagues depend on. The moment the wrapper has regular users, you own uptime, evaluation, security review, access control, and support, whether or not anyone budgeted for them. Our rule of thumb from the pilot world applies in full: the demo is roughly 20% of the work. The analyst's spreadsheet wrapper is not a scandal; unowned, unreviewed wrappers multiplying across departments is Shadow AI with extra steps.
Building hides its costs in the treadmill. Beyond the obvious (scarce talent, evaluation infrastructure, serving costs), the deep cost is perpetual migration: every model generation forces you to revalidate, retune, and sometimes rearchitect. A build is not a project with an end date. It is a standing capability with a payroll, and it should be approved as one.
A Default Posture
Frameworks earn their keep by producing defaults, so here is ours.
Buy for commodity capabilities, which is most of them, and negotiate data terms like they matter, because they do. Wrap when the capability is specific to your workflow, the value is measurable, and a named owner exists; keep the wrap thin so the improving model layer works for you instead of against you. Build only when the capability is genuinely differentiating, the volume justifies it, and you are prepared to fund a team, not a project.
Then revisit the whole portfolio yearly, without sentiment. The boundary between these categories moves every time the model layer improves: yesterday's justified build becomes today's commodity purchase, and a wrap that quietly accumulated two thousand users may have earned a promotion to something more deliberate. The companies that get this right are not the ones that chose correctly once. They are the ones that noticed when the right answer changed.
Facing a build-buy-wrap decision and want a second opinion? Get in touch. We help organisations make the call, and design the operating model that keeps it true in year two.