The build-or-buy question usually gets asked too early. It arrives as “should we get something custom built, or is there a product for this?” — before anyone has settled what this is, which means the answer is being chosen before the problem is described.
It is also framed as a binary, and it is not one. Almost every workable answer sits between the two poles, and knowing which point on the spectrum you are aiming at makes the decision considerably easier.
The spectrum, not the switch
Four positions, in ascending order of how much of it is yours:
- Buy a product and use it as shipped. Someone else's opinion about the process, adopted wholesale. Fastest, cheapest, and correct far more often than pride allows.
- Buy a product and configure it heavily. Their process, bent toward yours. This is where most enterprise software lands, and it carries a specific hidden cost: configuration is rarely portable and rarely documented, so it becomes custom work that nobody recognizes as custom work.
- Assemble from components. A model provider, a vector store, a queue, your systems of record, and the logic between them. Most of the parts are bought; the arrangement is yours.
- Build from scratch. Genuinely bespoke, including the parts that are available off the shelf. Rare, and rarely the right call outside of an actual product company.
The interesting observation is that the third position — assembly — is where most good answers now live, and it is the one least well described by either word in “custom versus off the shelf”.
What actually decides it
Is the process a differentiator or a commodity?
This is the single biggest determinant and it is worth being unsentimental about. If the way you do this thing is part of why customers choose you, custom is defensible. If it is a thing every company in your industry does approximately the same way, buy it, and spend the saved effort on the part that is actually yours.
The common error is applying that test at the wrong level. A company is genuinely distinctive. Its expense approval process is not. Assess the process, not the company.
Does something fit most of it, and does the rest matter?
If a product covers the large majority of what you need, the decision turns entirely on the remainder — and specifically on whether the remainder is load-bearing. A gap in a report is an inconvenience. A gap in a compliance step, a customer-facing commitment, or the one calculation your pricing depends on is not, and no amount of coverage elsewhere compensates for it.
Ask what happens if the gap is simply never filled. If the honest answer is that people will work around it in a spreadsheet, you have found the real cost of buying, and it is usually larger than it looks because the spreadsheet becomes permanent.
Where does the data have to be?
Sometimes this decides it outright, and it decides it early. If a contractual or regulatory constraint means certain data cannot leave a boundary, the set of viable products narrows fast and the assembled option becomes more attractive — not because it is better, but because it lets you place each component where it has to be.
Worth settling this before evaluating anything. It is the constraint most likely to invalidate a shortlist after two months of evaluation.
Who owns it in year three?
Every custom thing needs somebody who understands it, and that somebody has to still be there. This is the question that most often converts an enthusiastic build into a sensible buy, and it should be asked while the enthusiasm is at its peak rather than afterwards.
The mirror question for buying: what happens if the vendor is acquired, changes its pricing model, or discontinues the tier you are on? Neither path is risk-free. They are different risks, and the useful exercise is naming which one your organization is better equipped to absorb.
The bad reasons, in both directions
Building because “our business is unique”. Almost always true about the business and almost never true about the process being automated. Test it by describing the process to somebody in a different industry. If they recognize it immediately, it is a commodity process in local clothing.
Building because a demo was unimpressive. A poor demo is evidence about a vendor, or about the person giving it. It is weak evidence about the category.
Buying because of a deadline. Products install quickly and integrate slowly. A deadline that makes buying look fast is usually measuring the wrong phase — the calendar cost lands in the integration and the data work, and it lands whichever way you go.
Buying because of somebody else's case study. A published result describes an organization whose constraints you cannot see. It is a reason to take a call, not a reason to decide.
One question that resolves a surprising share of these: what is the thing here that only we can decide? Whatever that is, keep it — encode it deliberately, document why, and make it changeable. Buy everything on either side of it. That single split is most of a build-or-buy strategy.
“Custom” means something different than it did
This is the part most likely to be out of date in people's heads, and it changes the arithmetic.
Custom AI work used to mean assembling a training set and training a model, which was expensive enough that the build-or-buy question was largely settled by budget. That is now the uncommon case. With capable general models available as a service, the custom part is almost never the model — it is everything around it: which data the system can reach and under whose authority, what it is allowed to do without a human, how failure is handled, and how you know whether it is working.
Which means the practical answer for most mid-market companies is not one of the four positions above but a specific combination: buy the model, buy the platforms, and build only the seam. The seam is where the decisions you actually care about are encoded, and it is small enough to be understood by people who did not write it — which is the property that matters in year three.
How to run the decision
In order, and none of it needs a vendor present:
- Write down the process, in steps, as it is performed today. Not as documented — as performed.
- Mark each step commodity or differentiator, and be strict about it.
- Name the data each step touches and any constraint on where it can live.
- Only now look at products, and evaluate against the differentiator steps rather than the feature list.
- Assume you will build the seam regardless, because you will.
If a step is a differentiator, encode it. If it is a commodity, adopt somebody's opinion about it and stop thinking about it.
Where this work sits
Everything above is labor and judgment. The models, the platforms and the storage stay in your name and you buy them directly — nothing here is resold or licensed through us, which is deliberate, because a firm that earns on what it recommends cannot give you a straight answer to the question this post is about.
The service page for the assembly half is AI integration: choosing what to build, then connecting it to the systems you already run. If you are still at the step above that one — deciding whether any of this is the right place to spend — that is fractional CIO work, and it is a cheaper question to answer first.
Related reading: Data cleansing before an AI project — the work that lands the same either way, because both paths read the same data. And what API integration costs you after it ships, which is what the seam costs to keep once it exists. And what drives the cost of an AI agent — if the answer above was build, this is what the number is made of.