AI use cases: buy, extend, or build
A use case that passed the three gates still has to answer one more question: why build anything at all? There are three ways to get an AI capability, and they come in a strict order. Buy a finished product if it fits. Extend a platform you already run if it gets roughly 80% of the way there. Build custom only when the use case truly differentiates you. Default down the list. Every step down is a step up in cost, risk, and standing obligation, so each step needs a written reason.
What the three paths actually mean
Section titled “What the three paths actually mean”Buy means a finished product exists whose core job is your use case. Meeting summarisers, contract review tools, support deflection bots, coding assistants: whole categories of AI products now exist, and inside a category the mature ones are hardened by thousands of customers. You get someone else’s security team, model upgrades, and roadmap for a subscription fee. What you give up is fit: the product does what it does, and your process bends to it, not the other way round.
Extend means software you already run gets you most of the way there. CRMs, helpdesks, ERPs, and document platforms are all growing AI features with extension points: custom knowledge sources, custom actions, configurable workflows. Extending means the vendor keeps carrying the platform while you add the missing piece, typically a connector to the system that holds your grounding data, or an action tuned to your process. You maintain the extension. The vendor maintains everything else.
Build means you own the whole stack: model choice, orchestration, retrieval, evaluation, monitoring, access control, and every migration when a model is deprecated. Nothing is carried for you. That is sometimes exactly right, and it is the most expensive sentence in this track.
The order is a total-cost argument
Section titled “The order is a total-cost argument”Building feels like the ambitious choice and buying like the boring one. Total cost of ownership says the opposite. The quote you see for a custom build is development time, and over the system’s life that is often the smallest line. The lines that dominate:
| Cost line | What it covers | Buy | Extend | Build |
|---|---|---|---|---|
| Tokens and capacity | Every request, every day, forever | In the fee | Mostly in the fee | Yours |
| Infrastructure | Hosting, retrieval store, gateways, logging | Vendor’s | Vendor’s, plus your extension | Yours |
| Maintenance | Model deprecations, prompt drift, breaking API changes, eval upkeep | Vendor’s | Shared | Yours |
| Governance | Audit trail, access control, the guardrails your autonomy tier demands | Largely built in | Partly built in | Yours to design and staff |
A product vendor amortises all of this across every customer. A platform amortises most of it. A custom build, you carry alone, at your volume, with your team. That is why the bar for building is not “we could” but “this use case encodes something about how we compete that no product could ship.” If the answer is genuinely yes, build. And even then, build only the thin differentiated layer and rent everything underneath it.
”Buy X” is a decision, not a defeat
Section titled “”Buy X” is a decision, not a defeat”An evaluation that ends in “buy the product, here is why, here is what it will not cover” is a decision-ready answer. It is not a failed project. It is the expensive lesson you did not have to pay for: the same clarity a two-year build would have produced, reached in weeks instead.
The reason you rarely hear this answer is structural, not technical. A consultancy paid by build hours has no incentive to end its analysis with “you should not build.” That is worth naming plainly, because it tells you how to weight advice.
A worked example
Section titled “A worked example”A mid-sized services firm wants first-draft answers to support tickets, grounded in its internal knowledge. It passed the gates: the grounding lives in a homegrown operations database, the number is average handling time per ticket, the support lead owns the process.
Buy check. Several finished support-AI products handle ticket answering well. None connects to the homegrown database out of the box, and without that connection the product would guess. Buy alone fails the grounding gate.
Extend check. The helpdesk platform the firm already runs offers an AI answering feature plus an API for custom knowledge sources. One connector, syncing the operations database into the platform’s knowledge store, gets the use case live. The platform carries the model, the interface, and every upgrade; the firm maintains one connector.
Build check. Building would mean owning retrieval, the answer interface, evaluation, and every model migration, for the same result the extension delivers. The only genuinely differentiated asset is the operations data, and the connector already captures that.
Decision: extend. The firm builds exactly the differentiated part and rents everything else. A different firm, with a plain knowledge base and no custom source, walks the same path and stops at buy. A third, whose entire competitive edge is a proprietary triage logic no platform can express, walks it and lands on build. The path is the method. The stopping point is your evidence.
Whichever path you choose, the choice only pays if the value is proven, not asserted. That takes a baseline and a formula.