MODULE 5 · LESSON 1
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolThe Three Routes and How to Choose
The three routes
Buy. A finished product for a defined job — a contract review tool, a service desk assistant, a document extraction platform. You configure it; you do not construct it.
Assemble. Combine existing components — a model accessed through an API, a retrieval layer over your own documents, workflow automation — into something specific to you. Substantially less work than building, substantially more control than buying. This is where most bespoke organisational AI now sits, and it barely existed as a route five years ago.
Build. Train or heavily adapt a model on your own data with your own team. Rare, expensive, and correct in a narrow set of circumstances.
The distinctiveness test
The question is not "what can we afford" or "do we have engineers". It is:
Is the thing we would build genuinely distinctive to us — and is that distinctiveness worth money?
Buy when the problem is generic. Extracting fields from invoices, transcribing calls, classifying support tickets, checking contracts against a playbook. Thousands of organisations have this problem in almost the same form. A vendor has already met the edge cases you have not encountered yet, and their product improves from everyone's usage including your competitors'. Building here means paying to reach a standard already available.
Assemble when the shape is generic but the content is yours. You need an assistant that answers from your policies, over your documents, in your terminology. The mechanism is standard; the knowledge is not. This is the most common correct answer for organisations of any size, and it is what most "we need our own AI" requests actually mean.
Build when the data or the problem is genuinely unlike anyone else's and that difference is the business. A specialist manufacturer with twenty years of defect images nobody else has. An insurer whose claims history is the actual asset. Even then, the honest question is whether you need to build the model or only to hold the data and assemble around it.
Why external sourcing wins more often
The NANDA direction is not surprising once you list what a vendor has already absorbed:
That last point deserves weight. Internal builds concentrate knowledge in very few people, and organisations consistently underestimate how much of a system lives in one person's head until they resign.
When building is right
Do not read the above as never build. Building is correct when:
- The data is the moat, and handing it to a vendor gives away the advantage.
- No adequate product exists because the problem is genuinely unusual.
- Regulation or sovereignty requires processing you control end to end.
- The economics invert at your scale. Per-usage pricing that is trivial at low volume can exceed the cost of running your own at very high volume — a real calculation, worth doing, and one that changes as prices move.
Note that three of those four argue for controlling infrastructure and data, not for training your own model. That distinction saves a great deal of money.
A pattern worth being able to recognise, because it is common and expensive.
A mid-sized company decides to build rather than buy. The stated reasons are always the same three: our processes are unique, we need full control, and buying creates dependency.
Examine each.
"Our processes are unique." Occasionally true, usually not. Every organisation experiences its own processes as distinctive because it knows the exceptions intimately. The test is not whether your process feels unique but whether a vendor's product genuinely cannot be configured to it — which is answerable by making them try during evaluation, at their cost.
"We need full control." Control over what, specifically? Over data location, which good vendors offer. Over the model, which you probably do not need. Over the roadmap — legitimate, and the real answer to it is a contract term, not a build.
"Buying creates dependency." True. Building also creates dependency, on the two engineers who understand the system, who are harder to replace than a vendor and give less notice.
Underneath, the actual driver is frequently that building is more interesting, confers more status, and looks like strategy — while buying looks like procurement. This is a real organisational dynamic and it is worth naming out loud rather than arguing around, because it does not respond to analysis.
The productive move is to make buying the default and require the build case to clear a bar: what specifically can we not obtain, and what is that worth? If the answer is a list of configuration preferences, buy. If it is genuinely a moat, build — and you will find the case makes itself.
An organisation needs an assistant that answers staff questions from its own internal policies, in its own terminology. Which route fits?
Buy, assemble, build
Click to flipBuy a finished product for a generic job; assemble standard components when the shape is generic but the content is yours; build only when the data or problem is genuinely unlike anyone else's.
Click to flip backBuy generic problems, assemble when only the content is yours, and build only where the data or problem is genuinely unlike anyone else's. Externally sourced projects succeed roughly twice as often, because vendors have already absorbed the long tail, the integrations, the operational discipline and the maintenance — and their systems survive resignations. Make buying the default and require the build case to name what specifically cannot be obtained and what that is worth.