How do we cost the build option honestly?

Take the engineering estimate for the working version and then add the four things that never make it into the estimate: building an evaluation set from real inputs, handling the failure cases rather than listing them, cost controls that survive a traffic spike, and whoever is on call the first time it answers wrongly in front of a customer. In our experience those four together are frequently larger than the original estimate, and they are the reason built features get abandoned rather than the model quality.

Is a vendor safe from a compliance point of view?

It depends on the vendor and on what you send them, and the answer is in their subprocessor list rather than in their marketing. The question worth asking is which model provider sits behind them and whether your data is used for training. If they will not answer that in writing, that is the answer.

What if we build it and the models get better?

That is the argument for keeping the model choice swappable and for holding an evaluation set you can rerun. Teams that built one are able to change model in an afternoon and know whether quality moved. Teams that did not are guessing, and they tend to stay on whatever they launched with long after it stopped being the right choice.

Can we start by buying and build later?

Often, and it is usually the right sequence. Buy to find out whether customers use it at all, then build the version that is specific to you once you have the usage data to justify it. The thing that makes this hard later is data lock-in, so the question to ask the vendor on day one is how you get your data out.

Compare

Should we build our AI feature or buy it?

The short answer

Buy, unless the feature is the thing customers choose you for or the data behind it is something a vendor cannot get. Most AI features are not differentiators, they are table stakes, and building table stakes yourself means carrying evaluation, monitoring, model upgrades and failure handling forever in exchange for a feature nobody switches to you for. The test that settles most cases: if a competitor shipped exactly this feature next month using an off-the-shelf vendor, would you lose customers over it? If not, buy it and spend the engineering on the thing they cannot copy.

Why this comes up

The situation, before the answer

01
A vendor quote landed and the number looks large next to an engineer saying it is two weeks of work.
02
The two-week estimate is for the demo. It is not for the evaluation set, the failure cases, the cost controls, or the on-call rota when it answers wrongly at scale.
03
Meanwhile the buy option carries its own bill that nobody has read: per-seat pricing that scales with your growth rather than with your usage, and a data boundary your security review has not looked at yet.

Side by side

The comparison, on the dimensions that decide it

Shapes rather than figures. Salary bands, day rates and vendor prices move by an order of magnitude between markets, and a number here that you held us to would be worse than none.

Should we build our AI feature or buy it?
Dimension	Build itYour engineers, your repository, a model API underneath.	Buy a vendorA product that does this, integrated into yours.	Buy the platform, build thinSomeone else runs the infrastructure; you write the part that is specific to you.
Time to something customers can use	Weeks for a working version, then longer than anyone estimates for the parts that make it safe to leave running.	Days to weeks, mostly spent on integration and on your security review.	Between the two, and closer to buy than teams expect.
What it costs, in shape	Engineering time up front, then inference and maintenance forever. The maintenance is the part left out of the estimate.	A recurring fee that usually scales on seats or volume. Predictable, and it never goes away.	A platform fee plus your inference, plus a smaller slice of engineering time.
Cost at ten times the usage	You control it, and you also carry it. This is where a feature that looked fine at launch stops paying for itself.	Whatever the contract says. Read the overage terms before you sign, not after the good quarter.	You control the inference, which is the part that scales fastest.
Quality when it goes wrong	Yours to fix, which is slow, and yours to detect, which is the harder half.	Theirs to fix, on their timeline, and you explain it to the customer either way.	Split, and the split is worth writing down before you need it.
Where your data goes	Your infrastructure and the model provider you chose. One boundary to defend.	Your data in a third party, plus whichever model provider they use. Two boundaries, and you only control one contract.	Similar to build, with the platform in the middle.
Does it differentiate you	Only if the thing being built is genuinely specific to you. Most are not.	No, and that is fine when the feature is table stakes.	The thin layer can, which is the argument for this option.
What you own if you stop	Everything, including the obligation to keep it running.	Nothing, and migrating off is a project of its own.	Your layer and your data. The platform is replaceable in principle and rarely in practice.

Deciding

Which one, and when

01
Build it
- The feature is the reason a customer picks you over the alternative.
- It depends on data a vendor cannot see, which is usually your own operational history.
- You are already running production AI, so evaluation and monitoring exist rather than being invented for this.
- The unit economics only work at a cost level a vendor will not price to.
02
Buy a vendor
- The feature is expected rather than chosen. Search, summarisation and support triage are usually here.
- You need it this quarter and the alternative is a maybe.
- Nobody on the team has run an evaluation set before, and this is not the feature to learn on.
03
Buy the platform, build thin
- The hard part is your prompt, your retrieval and your data, and the boring part is everything around it.
- You want to keep control of the model choice and the inference bill.
- You expect to move fast on the specific part and not at all on the infrastructure.

The limit

What this comparison gets wrong

The comparison assumes the feature should exist, and often the real answer is a fourth option nobody put on the list, which is not shipping it. It also treats "build" as one thing when a rules engine and a model are wildly different builds, and a surprising share of features proposed as AI are a deterministic problem wearing an AI hat. Where that is true, building is both the cheapest option and the one no comparison table catches.