Comparison

Build or buy?

We build custom AI systems, so treat our answer with appropriate suspicion — which is exactly why this page leads with the case for buying.

BUY, IF YOU CAN

If an existing product does 80% of what you need, buy it. A team of engineers has spent years on the edge cases you have not thought of yet, it works on Monday, and someone else carries the maintenance.

The instinct to build is usually driven by the last 20% — a workflow that does not quite fit, a field that is missing, an integration that is not there. That gap feels intolerable in an evaluation and is frequently tolerable in practice. Adapting your process to a good product is often much cheaper than building software to preserve a process that was itself an accident.

A useful discipline: before commissioning custom work, run the off-the-shelf option for a month with real users. A meaningful share of the "we need custom AI" conversations we have end there, and we would rather they ended there quickly.

WHEN BUYING STRUCTURALLY CANNOT WORK

Your data is the differentiator

If the value comes from your own documents, history or domain knowledge, a general product cannot deliver it. It has no access to what makes your answer better than a competitor's — and that is the definition of a moat you cannot buy.

The workflow is the product

Where the AI has to sit inside a process specific to how your business works, configuring a general tool to fit becomes more expensive and more brittle than building for it directly.

Data cannot leave your perimeter

Most AI products are multi-tenant SaaS. If your data may not be processed by a third party, most of the market is unavailable regardless of fit.

You are selling it

If the AI capability is part of what your customers buy, outsourcing it to a vendor means your product roadmap runs on someone else's schedule, and your margin includes their markup.

The economics invert at your volume

Per-seat or per-request pricing that is reasonable at 50 users can be absurd at 5,000. Custom development is a capital cost against an operating one — worth modelling at projected volume, not current.

Integration exceeds the build

Occasionally connecting a product to your systems costs more than building the capability inside them. Rare, but real for organisations with unusual internal architecture.

THE COMPARISON

	Buy	Build
Time to first value	Days to weeks	2 weeks to 6 months
Upfront cost	Low	Significant
Ongoing cost	Per seat or per use, forever	Hosting plus maintenance
Fit to your process	Adapt to the product	Exact
Uses your proprietary data	Limited	Fully
Differentiation	None — competitors buy it too	Yours
Maintenance burden	Vendor	You or a partner
Roadmap control	Vendor decides	You decide
Data residency options	Whatever they offer	Whatever you need
Risk if it fails	Switch vendors	Sunk cost

Neither column is the right answer. The decision is which row is binding for you — usually only one or two of them are.

THE HYBRID PEOPLE FORGET

The framing is a false binary more often than not. The strongest pattern we see is buying the commodity layer and building only the differentiated part: use a hosted model rather than training one, a managed vector database rather than operating a cluster, an off-the-shelf CRM rather than writing one — and build the retrieval, evaluation and workflow logic that is specific to you.

That keeps the custom surface small, which keeps it maintainable. A common failure is building everything because one part genuinely needed building; the resulting system is large, and its size is what eventually kills it.

QUESTIONS

QUESTIONS — 4

With your own data and your own evaluation set, not the vendor demo. Ask for a trial on real inputs, including the hard ones. Ask how quality is measured and what happens when it is wrong. Vendor demos are constructed from cases that work, which is reasonable of them and useless to you.

That is a perfectly good outcome — you got value immediately and learned what you actually need, which is worth a lot when you do build. The thing to protect is data portability: make sure you can export your data and any accumulated labels or corrections, because those are the asset.

Much less than it was. Foundation models removed the need to train from scratch, so the work is engineering around a model rather than machine-learning research. A focused system that would have been a year and a research team in 2019 can be six to twelve weeks now. Ongoing inference cost is the newer consideration, and it is one to model early.

We do, regularly, and it is not altruism — an engagement we take on that should have been an off-the-shelf purchase ends badly for both of us and produces no reference. If a product does the job, saying so on the first call is the cheapest way to earn a call about something we should genuinely build.

Keep reading

30-minute call · no deck