Choosing

Should we just build this ourselves on a model API?

Any competent developer can wire a model API to a chat box in a weekend, and the result will be impressive. That is why this question deserves a straight answer rather than a sales one: the prototype is not the hard part, and knowing which part is hard is the whole of the decision.

The prototype is ten per cent, and it is the fun ten per cent

What the weekend build does not include: keeping the knowledge base in step with a website that changes, deciding what happens when retrieval finds nothing, rate limiting, abuse handling, per-tenant isolation if you have more than one site, conversation logging you can audit, a way to see what was answered wrongly, and the behaviour when the provider returns an error. Each is unglamorous and each is where the running cost lives.

The two parts that are genuinely hard

First, refusal. Making a model answer is easy; making it reliably decline what it should not answer, in three languages, and stay declined after a prompt change, is the work. Second, ingestion that survives reality - pages that move, duplicate content, a sitemap that lies, a crawl that silently stops. Teams consistently underestimate the second and discover the first in production.

When building is the right answer

If the assistant is core to your product rather than support for it. If you need behaviour no vendor offers. If you have an engineer who will own it next year, not just this quarter. And if the content it answers from is already structured and stable - because the hardest part of buying is also the hardest part of building, and it is not the model.

The question to ask either way

What happens when it does not know? If your prototype answers anyway - and most do, because that is the default - you have not built the thing you need yet. Asking a vendor the same question is the fastest way to tell whether they have. Anyone whose answer is about accuracy rather than refusal is describing a demo.

Frequently asked questions

Can we just build an AI assistant ourselves?
The prototype, yes, in a weekend. What it leaves out is keeping the knowledge base in step with a changing site, reliable refusal in three languages, abuse and rate limiting, auditable logs, and behaviour when the provider errors. That is where the cost lives.
What is the genuinely hard part?
Refusal and ingestion. Making a model answer is easy; making it reliably decline what it should not, and stay declined after a prompt change, is the work. And ingestion has to survive pages that move, duplicates, a sitemap that lies and a crawl that stops silently.
When is building the right choice?
When the assistant is core to your product rather than support for it, when you need behaviour no vendor offers, and when an engineer will own it next year rather than this quarter. Otherwise you are maintaining infrastructure to avoid a subscription.
What should we ask a vendor to compare fairly?
What happens when it does not know - verbatim, with an example. A vendor who answers about accuracy rather than refusal is describing a demo. Ask the same question of your own prototype; most answer anyway, because that is the default.
Does the choice depend on the model we pick?
Less than anyone expects. The model is the part that improves on its own and the part you can change. What decides whether the assistant is useful is the content it answers from and the rules about what it refuses - neither of which comes from the model.

Get in touch

Leave your details and we will reply. You do not need a sales call to get an answer.