AI Chatbot Development: Cost, Timeline & Scope

Short answer: scope decides everything. A grounded assistant that answers from your documentation is four to six weeks. One that takes actions in your systems of record is three times that, because it stops being a retrieval problem and becomes a distributed-systems problem. Most projects are quoted as the first and scoped as the second.

Nearly every AI chatbot development enquiry we get describes the same thing in the first email — “an assistant that knows our product” — and means one of three quite different systems. Establishing which one is the entire value of a scoping conversation, so let us start there.

The three shapes, and why the difference is the budget

	Deflector	Grounded assistant	Agentic assistant
Does what	Answers common questions	Answers from your corpus with citations	Acts on your systems
Core engineering	Content curation	Retrieval quality	Tool contracts, auth, idempotency
Typical build	1–2 weeks	4–6 weeks	3–5 months
Fails by	Missing the question	Answering from the wrong passage	Doing the wrong thing to real data
Right when	High-volume repetitive queries	Large corpus, knowledge-worker users	The answer requires a lookup or a change

The jump from column two to column three is where budgets break. A grounded assistant that gets an answer wrong shows a user a bad paragraph. An agentic assistant that gets it wrong issues a refund, cancels an order, or writes to a patient record. Once a system acts, it needs the engineering discipline agents require — idempotency so a retry does not double-charge, authorisation so it acts only where permitted, and audit trails so you can reconstruct what happened.

Be honest about which column you are in before anyone quotes you.

What actually drives the cost

Not the model. The model is a line item and a shrinking one. Five things move the number:

Corpus quality. Clean, well-structured documentation is the single biggest cost lever in custom chatbot development. A tidy knowledge base is a fast project. Ten years of contradictory PDFs, three wikis and a Slack archive is a data-cleaning project with a chatbot attached, and pretending otherwise is how timelines slip.

Number of systems it must reach. Each integration carries auth, rate limits, error semantics and a staging environment that behaves differently from production. Two integrations is not twice one — it is roughly twice one plus the reconciliation between them.

Permission complexity. If every user may see everything, retrieval is straightforward. If retrieval must respect per-user permissions, you need a permission-aware index, and that constraint reaches all the way back into ingestion. This is the requirement most often discovered late and it is expensive when it is.

How wrong it is allowed to be. A marketing assistant and a clinical assistant are not the same project. Regulated domains need deterministic paths for anything consequential, evaluation harnesses, and review gates — easily half the engineering.

Languages and channels. Each additional channel is its own delivery surface with its own formatting and session model.

How long does it take to create a chatbot?

For a grounded assistant over a reasonable corpus, four to six weeks:

Week 1 — corpus assessment, an evaluation set built from real user questions, and agreement on what the assistant must never get wrong.
Weeks 2–3 — ingestion, chunking, hybrid retrieval, grounding and citations.
Week 4 — guardrails, handoff to humans, resolution metrics and traces.
Weeks 5–6 — evaluation against the week-one set, tuning, deployment.

That is the honest range for the middle column above. A scripted FAQ bot on a platform is days. One that takes actions in your systems of record is three to five months, and the extra time is integration and failure handling rather than anything to do with the model. The variable that moves the number most is not the build: it is how long it takes to get access to the corpus and to a person who can say which answers are correct.

The evaluation set comes first on purpose. Without it, every later change is a matter of opinion, and you will spend the last two weeks arguing about whether a tweak helped.

When a platform is the right answer

We build custom assistants and we still tell a good number of people to use a platform. Intercom, Zendesk and the rest have solved deflection well, they ship with analytics you would otherwise build, and they are live in days.

Use a platform when your content is public-facing, permissions are uniform, you need it this month, and nothing the assistant does writes to a system of record. That describes a lot of support use cases and there is no prize for building it yourself.

Custom chatbot development earns its cost when at least one of these is true: retrieval must respect per-user permissions; the assistant must act in systems the platform does not integrate with; your data cannot leave your infrastructure; the domain is regulated enough to need deterministic handling and an audit trail; or per-seat pricing has become the dominant line item at your scale.

What changes for enterprise chatbot solutions

At enterprise scale the hard part is almost never the conversation. It is that the assistant now sits inside an organisation with existing access control, an audit obligation, several systems of record that disagree with each other, and a legal team with a view on what it may say.

Concretely: permission-aware retrieval rather than one shared index; logging detailed enough to reconstruct any answer months later; a deterministic path for anything with regulatory consequence; and a deployment story that satisfies your data residency rules. None of those are conversational features, and none of them can be configured into a platform after the fact.

Grounding is architecture, not instruction

The most common failure in production is confident invention. “Only answer from the provided context” in a system prompt is a request, not a constraint, and it will be ignored under pressure.

What works is structural: retrieve first, and if retrieval returns nothing above a relevance threshold, the assistant says it does not know and offers a handoff rather than generating. Every claim carries a citation the user can open. We covered the mechanics of this in how to stop your RAG system from hallucinating, and it applies identically here — a chatbot is a retrieval system with a conversation on top.

Measure resolution, not engagement

Engagement metrics flatter chatbots. Long conversations usually mean the user is not getting what they asked for.

Track the rate of conversations resolved without human handoff, the questions where retrieval returned nothing, and the answers users explicitly rejected. That last set is your roadmap — it tells you exactly which content is missing, which is far more actionable than a satisfaction score. Wire traces and evaluation in from the first commit; instrumenting an assistant already in production is substantially harder.

How to scope yours

Answer these before requesting a quote, and the quote will be worth reading:

What must this never get wrong?
Who is allowed to see what, and does the assistant need to know?
Does it answer, or does it also act?
Where does the knowledge live today, and what state is it in?
What happens when it does not know?

Question three is the one that moves the number by a factor of three. Question five is the one most teams have not thought about, and it decides whether users trust the thing after week two.

The takeaway

Most chatbot projects are over-scoped in ambition and under-scoped in engineering. Build the grounded assistant first, measure resolution honestly, and add actions only where a measured queue justifies them. A narrow assistant that reliably resolves 40% of enquiries is worth considerably more than an ambitious one nobody trusts.

Tools referenced

EpochC provides AI chatbot development and AI agent development services, built on production RAG and retrieval systems. See how we put four sub-agents behind one conversational API, or start a project.

AI chatbot development: what it costs, how long it takes, and what to actually build