What single question settles it most often?

Whether the capability is something your organisation should be distinctively good at. If yes, owning it may justify considerable inconvenience. If it is infrastructure everybody needs and nobody competes on, buying it back is nearly always right, and the cost comparison is a formality rather than the decision.

Where do build estimates usually go wrong?

They stop at the first working version. Maintenance, updates as the underlying models and interfaces change, documentation and the risk concentrated in whoever built it are the larger and longer part. A build is not a project with an end; it is a running commitment that starts once the project finishes.

Is assembling components buying or building?

Both, and it is where most real answers land. You buy the expensive parts, the model and the platform, and build only the layer that encodes how your organisation actually works. That keeps the maintenance surface small while still producing something specific enough to be worth having.

Does the answer change over time?

Frequently, and usually in one direction. Capabilities that were worth building because nothing existed become worth buying once products mature, and teams that built early often carry systems long past the point where a purchase would be better. It is worth rereading the decision on renewal rather than treating it as settled.

Glossary

Buy versus build

Buy versus build is the choice between paying for a finished product and assembling the capability yourself, and it is usually settled by how close the work sits to what your organisation is actually for.

In plain terms

Buying means somebody else maintains it, improves it and answers the phone when it breaks, and you accept the shape they chose. Building means the shape is yours and so is everything else, including the person who keeps it working at half past six on a Friday. Most arguments about this are conducted as cost comparisons and are actually about something else: whether this particular capability is one you want to be good at.

Why it matters

Because the two options fail in opposite directions and the failure arrives late in both cases. Buy the wrong thing and you inherit somebody else's roadmap, discovering over a year that the feature you need is never coming. Build the wrong thing and you acquire a system with one expert, no documentation and a maintenance burden that nobody costed, which quietly becomes the reason a team cannot take on anything new. Neither shows up in the first month, which is why the decision deserves more than a spreadsheet.

How it works

Ask whether the capability is core before asking what it costs. If this is a thing your organisation is meant to be distinctively good at, owning it can be worth a great deal of inconvenience. If it is plumbing that every organisation needs and nobody wins on, buying it back is almost always the better trade even when the arithmetic looks close.

Price the build honestly, which means pricing the second year. The first version is the cheap part; what follows is maintenance, updates as models and interfaces change underneath you, documentation, and the cost of the one person who understands it going on holiday. Build estimates that stop at delivery are estimating the wrong thing.

Price the buy honestly too, which means reading past the licence. Setup, integration, review time and the eventual cost of leaving all belong in the comparison, and leaving them out is what makes buying look artificially cheap in exactly the way building looks artificially cheap when maintenance is ignored.

Consider the middle, because most real answers live there. Assembling bought components into something specific to you is neither pure option, and it is what most working AI systems actually are: a model somebody else trained, a product somebody else maintains, and a thin layer of your own that encodes how your organisation works.

Decide who is accountable when it is wrong. Buying gives you somebody to escalate to and limits on what they will accept; building gives you full control and full responsibility. For work that touches customers or regulated material, that distinction usually matters more than the money on either side.

What each option actually hands you

Set out this way the choice stops looking like a cost comparison, which is how it is usually conducted and why it is so often decided badly. Each column contains one genuine advantage and one genuine liability, and they are mirror images. The buyer gets maintenance, updates and a support obligation, and gives up the ability to change what the thing fundamentally is. The builder gets exactly the shape they want and takes on an open-ended commitment that outlasts the enthusiasm of whoever started it. Reading the two columns together also explains why the middle path is so common: assembling bought components lets you keep the shape decision for the small layer where it matters while leaving the maintenance obligation with the vendors of the large parts. That is not a compromise between the columns so much as a deliberate choice about which line of each you most want.

Seen in the wild

Assemble a bought model, a bought automation platform and a thin layer of your own logic, which is what most working systems turn out to be.
n8n
Buy a finished product for a capability everybody needs and nobody differentiates on, rather than recreating it internally.
Glean
Build on your own hardware where the data cannot leave, accepting the operating burden as the price of that constraint.
AnythingLLM

Common misconceptions

People assume

Building is cheaper because there is no licence fee.

In fact

The licence is replaced by salaried time, which is usually more expensive and always harder to stop. A build also carries a maintenance obligation that has no natural end, whereas a subscription can be cancelled. Comparing a build's first year against a purchase's first year flatters the build twice over.

People assume

Buying means we lose control.

In fact

It means you trade some control for somebody else's maintenance obligation, which is often the better half of that deal. What you genuinely lose is the ability to change the shape of the thing, so the real question is whether your requirements are unusual enough that the shape matters.

Questions

What single question settles it most often?: Whether the capability is something your organisation should be distinctively good at. If yes, owning it may justify considerable inconvenience. If it is infrastructure everybody needs and nobody competes on, buying it back is nearly always right, and the cost comparison is a formality rather than the decision.
Where do build estimates usually go wrong?: They stop at the first working version. Maintenance, updates as the underlying models and interfaces change, documentation and the risk concentrated in whoever built it are the larger and longer part. A build is not a project with an end; it is a running commitment that starts once the project finishes.
Is assembling components buying or building?: Both, and it is where most real answers land. You buy the expensive parts, the model and the platform, and build only the layer that encodes how your organisation actually works. That keeps the maintenance surface small while still producing something specific enough to be worth having.
Does the answer change over time?: Frequently, and usually in one direction. Capabilities that were worth building because nothing existed become worth buying once products mature, and teams that built early often carry systems long past the point where a purchase would be better. It is worth rereading the decision on renewal rather than treating it as settled.

Key takeaways

Decide whether the capability is core before comparing costs; that usually settles it.
Build estimates that stop at delivery are estimating the wrong thing.
Buy estimates that stop at the licence make the same error in the other direction.
Most working systems are a middle: bought components with a thin layer of your own.
Revisit the decision at renewal, because what was worth building often stops being so.