Founders asking “what does an AI chatbot cost in 2026?” usually want a number they can put in a board deck. Agencies that answer with a single figure are guessing, or selling a package that will not match your helpdesk, your identity provider, or your appetite for a wrong answer going to a customer. Cost is a stack of decisions: what the bot is allowed to know, what it is allowed to do, who reviews it, and whether you buy a vendor or build against your own Laravel or Node.js app.
This is how we explain chatbot budgets at DayDecoder, from Ahmedabad, to product teams in the US, UK, Europe and Australia. There is no invented industry average on this page. Ranges are typical and indicative, for orientation, not a quote. A 30-minute call is how we get to a number you can sign. If you want that call, use the contact form or write to contact@daydecoder.com.
Key takeaways
- Price the job, not the widget. A FAQ bot, a RAG assistant over private docs, and an agent that takes actions are different products.
- The usual cost drivers are integrations, retrieval quality, evaluation, human handoff, and compliance, not the model list price alone.
- Offshore versus onshore changes the engineering rate. It does not remove senior ownership, overlap hours, or the need for a review desk on your side.
- Buy when the workflow is generic and the data is not a moat. Build when the bot must live inside your product, tenancy, and process rules.
- Ask for a written slice: who works on it, what “done” means, and a monthly usage envelope labelled as indicative until traffic is real.
What “chatbot” means on an invoice
Three products get sold under the same word. Mixing them is how a cheap quote becomes an expensive rescue.
| Kind of bot | What it can do | What it cannot safely do | Where cost hides |
|---|---|---|---|
| Scripted or FAQ bot | Answer from a curated list, collect a few fields, hand off to a human | Reason over private tickets, invent policy, take account actions | Content maintenance, not the model |
| RAG assistant | Answer from your docs, tickets, or product data, with citations | Act in other systems unless you add tools on purpose | Ingestion, permissions, evaluation, stale documents |
| Tool-using agent | Look up an order, draft a refund, open a ticket, in some cases complete a workflow | Anything you have not given it an allowlisted, authorised tool for | Authorization, audit, retries, human approval |
If a proposal says “AI chatbot” and does not say which of the three you are buying, it is not a proposal yet. Our AI integration and automation work is usually the second or third kind, bolted onto an existing product, not a widget dropped on a marketing site.
What actually drives cost in 2026
Model vendors still charge for tokens. That line item matters, and it can dominate if you retrieve too much context or let a loop retry. For a serious product, it is rarely the first line item that should scare you. These are.
1. Discovery and the review desk
Someone has to list the intents, the sources of truth, the tone, and the cases that must never be auto-sent. That is product work. If your team cannot spare a reviewer, the agency will guess, and you will pay to unwind the guess. Budget time on your side, not only theirs.
2. Channel and identity
A bot on your logged-in app is a different build from a public website widget, Intercom, WhatsApp, or email. Each channel has session, auth, and rate-limit rules. “Make it work in Slack too” is a new project if identity does not already line up.
3. Integrations
Helpdesk, CRM, billing, order history, feature flags, your Laravel policies, your Node.js services. Every system is a connector, a mapping, a failure mode, and a test. This is usually where honest quotes diverge.
4. Retrieval (RAG)
If answers must come from your corpus, you are funding chunking, embeddings, a vector store or pgvector, ACL filters, and a job that keeps documents in sync. Skipping this and pasting a wiki into the system prompt is cheaper until the wiki changes or a tenant boundary appears. Read RAG explained for business owners before you accept “we’ll just add the docs”.
5. Evaluation and prompt operations
A frozen set of questions, expected citations, and “refuse” cases is part of the build. So is the habit of re-running it when models or prompts change. Teams that skip this do not save money. They pay in public corrections.
6. Human handoff and the UI
Transcript to the helpdesk, confidence display, “this was generated, here are the sources”, a way to thumbs-down an answer. This is product design, not a weekend of CSS. It is also how you sleep at night.
7. Hosting, observability, and compliance
Logs with tenant ids, token counters, retention, subprocessors, region. EU and UK buyers will ask for the data-flow diagram. US buyers in regulated industries will ask earlier than you hope. Drawing that diagram is cheaper than retrofitting it.
Indicative build ranges (not a quote)
These bands are typical of work we see and would expect to discuss in 2026. They are indicative, in US dollars, for a focused first version, excluding your internal time and excluding runaway model usage. Scope moves the number more than geography does.
| Slice | Typical build band (indicative) | What you usually get | What blows the band |
|---|---|---|---|
| Vendor widget, light configuration | Hundreds to a few thousand to wire in, plus vendor subscription | Public FAQ deflection, basic handoff | Custom identity, private data, brand-new channel |
| Custom FAQ / guided bot on your site or app | Mid four figures to low five figures | Your intents, your UI, analytics, handoff | Many locales, complex forms, poor existing content |
| RAG assistant over a defined corpus | Five figures; more if many systems or strict ACLs | Ingest pipeline, citations, tenant filters, eval set | Messy PDFs, permissions that change hourly, “all of Drive” |
| Agent with a few read or write tools | Upper five figures and up | Allowlisted tools, audit log, approval for writes | Payments, production mutations, weak existing APIs |
A discovery spike of a couple of weeks, typically a few thousand dollars, is often the cheapest way to learn which band you are in. We would rather sell that than a theatrical fixed price on an unwritten corpus.
Ongoing cost has two parts: model and retrieval usage (variable), and a retainer or dedicated capacity for prompt fixes, new documents, and incidents (mostly people). Usage might be modest at a few hundred conversations a day and uncomfortable at tens of thousands if context windows are fat. Put a per-tenant ceiling in from the start. There is no honest global “average chatbot bill” that belongs on this page.
Offshore vs onshore
DayDecoder is in Ahmedabad, India. We work with overseas clients on overlap hours, not on 2 a.m. stand-ups. Senior engineering time in India is typically billed below equivalent senior time in the US, UK, much of the EU, and Australia. That can matter. It is not a licence to quote a made-up percentage saving against “local rates”, and we will not.
What you should compare:
- Who you meet on the first call, and whether they still write code after the contract is signed.
- Whether you get git access, staging, and an NDA in week one.
- Whether the quote names the slice (FAQ vs RAG vs agent) and the integrations.
- Whether someone on your side still owns tone, policy, and the review desk.
A cheap offshore team that cannot describe tenancy in a vector store will cost more than a dearer team that can. A dearer onshore team that subcontracts the work without telling you has the same problem with extra account managers. We wrote down the operating rules in what working with an offshore company should feel like and how we think about dedicated team vs fixed price vs hourly.
For a chatbot that will keep evolving with your product, a small dedicated team is usually a better fit than a one-off fixed price. Fixed price fits when the intents, sources, and “done” list fit on one page. Hourly fits rescue work and production support. Pick the model for the uncertainty you actually have.
Build vs buy
Buy a vendor when the workflow is common, the data is not sensitive, and you need to learn in weeks. Many companies should start there for a public FAQ. Build custom when the bot must respect your tenancy, call your APIs, match your UI, or sit inside a workflow that is the product. Hybrid is ordinary: vendor for the commodity channel, custom RAG and tools where your data is the advantage. We go through that decision without ideology in custom AI software vs buying AI tools.
| Question | Lean buy | Lean build |
|---|---|---|
| Would a competitor with a generic widget look the same? | Yes | No: your data and process are the point |
| Can the vendor isolate tenants the way your app does? | Yes, and you have checked | No, or you cannot audit it |
| Do you need tools into billing, orders, or admin? | Rarely, or the vendor has the connector | Yes, through your own policies |
| Who owns prompts, logs, and deletion? | You can accept the vendor’s terms | You need the records in your cloud |
A budget you can defend in a board meeting
- Name the job and the channel in one sentence.
- Classify the bot: FAQ, RAG, or agent. Do not let the slide say all three.
- List integrations and data sources. Anything not on the list is out of scope.
- Set an indicative usage envelope (conversations per day, cap per tenant).
- Fund an evaluation set and a human handoff, not as extras.
- Choose engagement: fixed slice, dedicated capacity, or a short hourly spike.
- Write the kill switch: how you turn it off and what the customer sees.
If an agency cannot fill that list, they are not estimating a chatbot. They are estimating a demo. DayDecoder has 10+ years building software for 103 customers; we would still rather start from this list than from a round number.
Checklist before you sign
- Repo and staging are yours. Custom code is yours when paid.
- Model names are pinned. Provider keys never sit in the frontend.
- Logs include tenant, model, prompt version, and token counts.
- Write actions require the same authorization as a human in the admin UI.
- There is a documented path from a bad answer to a human.
- The quote says typical/indicative usage, and what happens if volume doubles.
Hidden work that still shows up on the invoice
Three items rarely appear on a first slide and almost always appear on a second invoice: content cleanup, evaluation writing, and the month after launch when real questions arrive. If your help centre contradicts itself, RAG will quote both paragraphs. If nobody on your side can spend two hours a week labelling “acceptable / refuse / escalate”, the agency will guess, and you will pay to unguess. If you launch without a prompt owner, the model will drift the first time a provider ships a quieter default.
None of that is a reason to panic. It is a reason to put a named person on your side in the proposal, and a short post-launch cycle in the same statement of work. Treat it as part of the product, the way you would treat analytics after a marketing site launch. DayDecoder will say this on a call even if it makes the first number look less magical. Magical numbers are how chatbot projects get a reputation.
A practical way to bound it: agree a slice, an eval set size (even 40 questions is a start), and a two-week hypercare window with a cap on hours. If you need more, you both can see why. That is cheaper than an open-ended “make it smart” retainer that nobody can audit.
Need a number for your product, not a blog band? Send the job, the channel, and the systems involved. We will say which band you are in and whether to buy, build, or spike first. See AI integration and automation or contact DayDecoder.
FAQ
Why will nobody give me a single price?
Because a public FAQ widget and a tenant-aware RAG assistant with billing tools are not the same product. A single price would be fiction. Ask for a band against a written slice, then a quote after discovery.
Is the model the expensive part?
It can be, at high volume with fat prompts. For most first versions, people, integrations, and retrieval quality dominate the build. Usage should be capped and visible per feature so it cannot silently overtake the engineering invoice.
Will going offshore cut the budget in half?
Sometimes the engineering rate is meaningfully lower. We do not publish a savings percentage, and we would not trust a vendor who does. Compare senior ownership, overlap with US, UK, EU or Australian hours, and whether you hold the git remote. Geography is one input, not a discount coupon.
Should we start with ChatGPT’s business plan and wrap our app later?
That is a valid way to learn the job. It is a poor production architecture if customers will type private data, or if you need citations and tools. Treat the vendor as a prototype unless it already meets tenancy and retention requirements.
What do you need from us to quote?
The job, the channel, where the data lives, who reviews answers, and whether the bot may take actions. Access to staging under NDA if the data is sensitive. Email contact@daydecoder.com with that list; a tidy brief gets a faster, more honest number than a long pitch deck.
Written by
Prakash Tank
Founder & Full-Stack Architect, DayDecoder
Prakash started as a certified Laravel developer and grew into a full-stack architect who owns a project end to end: requirements, architecture, development, deployment, and support. He designs event-driven systems with...
More about Prakash