Custom AI chatbot development means building a retrieval-grounded assistant on your own content and systems rather than configuring a template. The build splits into four hiring models: freelancer, in-house team, agency and dedicated developers. Cost, speed and long-term ownership move in opposite directions across those four.
This guide covers what the work involves, what it costs, what a quote should itemise line by line, who ends up owning the prompts and the retrieval index, and what each hiring model actually costs you over two years rather than over the first quarter. It also names the cases where you should not commission a build at all, which is an inconvenient thing for us to write, given that building these systems is what we sell.
If you have not yet decided between licensing a platform, hiring an agency and staffing an internal team, start with our companion piece on choosing between conversational AI companies. That one is about the category decision. This one assumes a build is on the table and deals with how to staff, scope, price and own it.
What does a custom chatbot development service actually cover?
A custom AI chatbot development service covers six pieces of work: discovery and use-case scoping, conversation and escalation design, retrieval architecture over your own content, integration with the systems your team already uses, adversarial testing, and deployment with ongoing monitoring. A project that skips discovery or skips testing usually ships something that answers the easy questions and falls apart on everything else.
Discovery decides which conversations are worth automating and which need a person every time. It is the cheapest place to make decisions and the most expensive place to skip. Conversation and escalation design is the decision logic underneath the chat window: when the assistant answers, when it asks a clarifying question, when it stops and hands over. Retrieval architecture is how the assistant finds the right passage of your documentation before it writes a word. Integration is how it reads a customer record, checks an order or opens a ticket. Testing means adversarial prompts and multi-turn conversations, not a rehearsed demo script. Deployment includes the part most quotes treat as optional: somebody watching the logs in month three.
Custom means the system is scoped around your business from the first session rather than configured from a template afterwards. The assistant knows what you sell, what your refund policy says in its exact wording, and how your team phrases a refusal. It reads from HubSpot, Salesforce, Zendesk, Freshdesk or an internal database because those connections were designed in, not because a connector happened to exist.
On your side, most engagements need three people: someone who owns the process being automated, someone with access to the systems the assistant needs to read from, and someone who can approve what it is allowed to say without reviewing every individual response. Fewer than three and scoping stalls waiting for answers. More than six and every review cycle adds a week.
Generic chatbot versus custom build
The difference between a template chatbot and a custom build shows up in four places: where the answer comes from, what the assistant can do after it answers, what happens when it does not know, and who can change it six months later.
| Dimension | Template or widget chatbot | Custom AI chatbot build |
|---|---|---|
| Source of answers | Pre-written responses and a fixed decision tree | Retrieval over your own documentation, policies and account data |
| Actions | Usually none, or a link to a form | Reads and writes to CRM, helpdesk and order systems through scoped API calls |
| Unknown questions | Loops back to a menu or repeats a fallback message | Hands off to a person with the full conversation attached |
| Domain language | Struggles with product-specific or regulated wording | Handles your terminology because it retrieves your wording |
| Change control | The vendor roadmap decides what is possible | Your team or your partner changes prompts, retrieval and rules directly |
| Exit | Configuration is held in the vendor's format | Source code, prompts and index definitions transfer if the contract says so |
None of that makes a custom build the right answer by default. A template chatbot handling twenty repeated questions on a marketing site is a sensible piece of engineering, and the section on when not to build one sets out the cases where it wins outright.
How a custom AI chatbot works
A production chatbot is three layers that have to agree with each other: a reasoning model that reads and writes language, a retrieval layer that fetches the right passage from your content, and an integration layer that lets the assistant see and change real records. Most failures happen at the seams, not inside any one layer.
The reasoning model, and why routing decides the bill
The model is the part buyers fixate on and the part that matters least to whether the project succeeds. What matters commercially is routing: sending short, high-volume, low-stakes questions to a small model and reserving the expensive one for conversations where being wrong costs something.
The arithmetic is public. Anthropic's published pricing, checked on 12 September 2026, lists Claude Sonnet 5 at $2 per million input tokens and $10 per million output tokens, Haiku 4.5 at $1 and $5, and Opus 5 at $5 and $25, with batch processing at half price and cached prompt reads at $0.20 per million tokens. Take a support conversation that sends roughly 4,000 tokens of retrieved context and prompt and returns 400 tokens of answer. On Sonnet 5's published rates that is about $0.012 per conversation, so 5,000 conversations a month lands near $60. That figure is arithmetic on a published price list, not a bill anyone has paid, and your own token counts will differ once you measure them. The point is the order of magnitude. For most support workloads, inference is not the expensive part. Engineering time is.
Open-weight models change the shape of the bill rather than removing it. Meta's Llama 4 Community License, which Meta publishes in full and which took effect on 5 April 2025, requires a separate licence from Meta above 700 million monthly active users, requires prominent display of "Built with Llama", and requires derivative model names to begin with "Llama". Apache 2.0 models carry none of those conditions. If you self-host, the cost moves to GPU hours: RunPod publishes its per-GPU rates openly, with an H100 SXM at $3.49 per hour on its secure tier as checked on 12 September 2026. Our guide to private LLM hosting works through when that trade is worth making.
Retrieval-augmented generation and the vector database
Retrieval-augmented generation, usually shortened to RAG, is the architecture that lets a general model answer from your specific content. The question is converted into a numerical embedding, compared against embeddings of your documents, and the closest passages by semantic similarity are passed to the model as context. The model answers from that context rather than from whatever it absorbed during training.
That solves two problems at once. Your answers stay current without paying to retrain a model every time a policy changes, and the model has something concrete to be grounded in, which is the main practical defence against confident invention. Vector stores in production use in 2026 include Pinecone, Weaviate, Qdrant and pgvector, and the choice matters less than the chunking strategy, the metadata attached to each chunk, and whether anybody has measured retrieval quality separately from answer quality. Teams that only measure the final answer cannot tell whether a bad response came from bad retrieval or bad reasoning, so they tune the prompt when the index was the problem.
Training a chatbot on your own data
Preparation is the unglamorous majority of the work. The content that usually goes into a support assistant's index includes product documentation and specifications, internal standard operating procedures and wiki pages, historical ticket threads and their resolutions, CRM records for customer and order context, material living in Notion, Confluence, SharePoint or Google Drive, and the policy documents covering returns, refunds, shipping and legal terms.
Data quality decides the outcome more than model choice does. A small, accurate, well-structured knowledge base outperforms a large and contradictory one, because contradictory sources produce confident answers that are wrong half the time and nobody can tell which half. Every engagement we run at XOVO Technologies starts with an audit of what exists, what contradicts what, and what is simply out of date. The most common finding is that two teams have been giving customers different answers to the same question for a year, and nobody noticed until a retrieval system surfaced both at once.
The integration and orchestration layer
Orchestration frameworks such as LangGraph and CrewAI manage multi-step conversations and tool calls. The Model Context Protocol standardises how an assistant connects to external data and tools; the MCP specification, revision dated 28 July 2026 and maintained under the Agentic AI Foundation, defines the host, client and server roles and the resources, prompts and tools a server exposes. Adopting a standard connection protocol matters mainly for a boring reason: it reduces how much bespoke connector code you own and have to maintain.
Integration detail is where estimates go wrong. Handoff behaviour is a good example. Zendesk's Sunshine Conversations allows only one active switchboard integration at a time, with others held in pending or standby state, as its switchboard developer documentation sets out, checked on 12 September 2026. That single constraint changes how a handoff is designed, and it is not the kind of thing that surfaces in a demo. Our chatbot integration guide for websites, Google apps and support tools goes through the connection patterns in more detail.
What does custom AI chatbot development cost in 2026?
Most custom chatbot builds we scope at XOVO Technologies fall between $8,000 and $150,000, and the figure that moves the total is not the model or the conversation volume. It is how many of your systems the assistant has to read from and write to, and how much of the conversation is genuinely autonomous rather than scripted.
These are our own scoping tiers as of September 2026, not a market survey. Other firms price differently, and a vendor quoting outside these ranges is not automatically wrong. Ask which tier they think they are quoting for.
| Tier | What it includes | Our typical range | Typical timeline |
|---|---|---|---|
| Foundational FAQ assistant | Single channel, scripted flows plus one model for open questions, no backend integration | $8,000 to $25,000 | 3 to 5 weeks |
| RAG-grounded assistant | Retrieval over your knowledge base, one or two system integrations, designed human handoff | $25,000 to $75,000 | 6 to 10 weeks |
| Multi-agent enterprise assistant | Orchestrated multi-step flows, three or more integrations, human-in-the-loop escalation by default, private hosting option | $75,000 to $150,000 and above | 10 to 16 weeks |
Two causes account for most overruns. The first is underestimating the content cleanup needed before retrieval works acceptably, which stays invisible until somebody actually indexes the material. The second is adding integrations mid-project rather than scoping them at the start, because each new system brings its own authentication model, rate limits and edge cases.
None of those ranges include recurring cost. Model usage, hosting and the monitoring effort after launch are separate lines, and they are the lines first-time buyers most often leave out of the business case. Ask for them as their own number before you sign anything, and read the next section before accepting a single-figure quote.
What a fixed-price chatbot quote should itemise
A fixed-price quote is only useful if you can see what is inside it. One number with the words "AI chatbot development" beside it transfers all the estimating risk to you, because every later disagreement becomes an argument about whether something was included.
Here is the line-by-line breakdown a complete quote should contain, what each line should say, and what it usually means when the line is missing.
| Quote line | What a complete quote states | What it means if the line is absent |
|---|---|---|
| Discovery and use-case scope | Named conversations in scope, named conversations explicitly out of scope, number of workshops | Scope gets decided later by whoever argues hardest, usually mid-build |
| Content audit and preparation | Number of source documents, who resolves contradictory content, whether cleanup is billed separately | The cleanup lands on your team in week three, unbudgeted, and the timeline slips |
| Retrieval build | Vector store, chunking approach, who owns the index definitions, how retrieval quality gets measured | You receive an index you cannot rebuild or evaluate without the vendor |
| Conversation and escalation design | Confidence threshold, escalation routes, refusal behaviour, tone rules | Escalation gets configured on launch day by an engineer guessing at policy |
| Integrations, one line per system | Each system named, direction of data flow, read or write, authentication method | "CRM integration" turns out to mean one read endpoint, and the write you assumed is a change request |
| Testing | Adversarial prompt testing, multi-turn tests, number of test conversations, acceptance criteria | Acceptance means the demo worked, and your customers run the real test |
| Security and compliance review | Access control model, logging, data residency, AI disclosure wording | The review happens after launch, at the point where fixing it costs most |
| Deployment and environments | Staging environment, rollback plan, who holds production credentials | There is one environment, and it is the one your customers use |
| Model and inference cost | Estimated monthly token or resolution volume, who pays the provider, what happens if volume doubles | The first invoice after a busy month starts an argument |
| Hosting and infrastructure | Where it runs, who owns the account, monthly floor cost | Your assistant lives in the vendor's cloud account indefinitely |
| Post-launch support | Response times, what is included each month, what is billed hourly | Month two support becomes a fresh negotiation, conducted while something is broken |
| Handover and ownership | Source code, prompts, index definitions, evaluation sets, assignment of rights | See the ownership section below, because this is the expensive omission |
| Change control | Rate for out-of-scope work, how a change gets agreed | Every request becomes a proposal, and delivery pauses while it is priced |
An underspecified quote is not usually dishonest. It is usually written by someone who has not thought about month six. The fastest way to tell the difference is to ask for the same quote broken into those lines and watch whether the total changes. If it goes up, the original number was missing work. If it stays the same but the lines read thin, the work was going to be thin.
Two more items belong in writing. What happens to the price if your content volume doubles between signing and indexing, since content growth during a build is normal and whether it is a change order or absorbed says a great deal about how the engagement will run. And what the vendor's assumption is about your team's availability, because "client provides subject matter expert access" with no hours attached is the most common hidden dependency in this kind of quote.
How long does it take to build and launch an AI chatbot?
A retrieval-grounded assistant connected to one or two systems typically takes six to ten weeks from kickoff to launch. A multi-agent build with several integrations and private hosting runs ten to sixteen weeks. The bottleneck is almost never the model. It is how clean your source content is and how many people have to approve the escalation rules.
The work runs through five phases, and they overlap more than a Gantt chart suggests:
- Discovery and use-case scoping, one to two weeks, deciding what the assistant will and will not handle
- Content and knowledge base preparation, one to two weeks and usually in parallel, covering cleaning, chunking and indexing
- Architecture and integration build, three to six weeks, covering the retrieval pipeline, the orchestration layer and the connections to your systems
- Testing, escalation tuning and stakeholder review, one to two weeks, running adversarial prompts and fixing handoff logic before customers see it
- Launch, monitoring and the first optimisation pass, ongoing, because real conversations always surface gaps a test script did not
Two things reliably add two to four weeks to any of those ranges: a legal or compliance review before launch in a regulated sector, and support for more than one language. Both are worth planning for at the start rather than discovering in week seven. A third, less predictable delay is a content owner going on leave during the preparation phase, which sounds trivial until the only person who knows which refund policy is current is unreachable for a fortnight.
Why the team you hire decides the outcome
Chatbot projects rarely fail on technology. The models available in 2026 are more capable and more accessible than the ones that shipped the previous generation of assistants. Projects fail on architectural decisions taken early by people who had not seen a production system before, on content nobody audited, and on the gap between a demo that answers ten rehearsed questions and a system that handles several thousand real ones a day.
What a generative AI engineer needs to be able to do
A competent engineer on this kind of build needs prompt design that produces predictable behaviour rather than impressive one-off answers, experience selecting and tuning a vector store and its indexing strategy, retrieval pipeline design using frameworks such as LangChain, LlamaIndex or LangGraph, backend engineering in Python or Node for orchestration and business logic, cloud deployment on AWS, Azure or Google Cloud, a clear view of when fine-tuning is justified and when retrieval is the cheaper answer, security practice appropriate to regulated data, and the integration work connecting CRM, helpdesk, commerce and messaging systems.
Very few individuals hold all of that. That single fact, more than any cost comparison, shapes the hiring decision that follows.
Mistakes that show up again and again
The failed or underwhelming deployments we get called in to look at share a short list of causes. Front-end developers were asked to build a retrieval system because they were already on the team. A no-code platform was chosen for a use case that needed integration depth the platform could not reach. Content was loaded without auditing, so the assistant answered confidently from a superseded policy. No fallback behaviour was designed, so out-of-scope questions produced either silence or invention. The system was treated as a one-off deployment rather than something needing a monthly review cycle, so it drifted away from the product it was describing. And nobody agreed in advance what "working" meant, so there was no number to argue about when the sponsor asked whether it was working.
The four hiring models for custom AI chatbot building
Four models cover almost every custom chatbot build: an independent freelancer, an in-house team, a development agency, and dedicated developers embedded with your team on a longer engagement. They differ on day-one cost, on how long production takes, on who holds the intellectual property, and on what happens in month thirteen.
Freelance AI developers
Independent specialists hired through Toptal, Upwork, Contra or a personal network are the fastest route from decision to first commit. Costs are lower on day one than any other model, the scope conversation is short, and you can engage for a defined piece of work without a long commitment.
The limitation appears the moment the project needs more than a prototype. A production assistant needs model integration, retrieval architecture, backend engineering, cloud deployment and security practice, and individuals who hold all of that are rare and heavily booked. Continuity is the second problem. A freelancer who takes a full-time role halfway through your build is not doing anything wrong, and you still lose the only person who understands your retrieval pipeline. The third issue is contractual and is covered below: without an explicit assignment clause, the code they write may not be yours.
Freelancers fit early-stage validation, a proof of concept before a production decision, or a specific gap in an existing team, such as bringing in one person purely for retrieval evaluation.
An in-house AI team
An internal team gives you the deepest product knowledge and the shortest feedback loop. The people building the assistant sit in the same standups as the people building the product it describes, and the institutional knowledge stays with you when a contract ends because there is no contract.
The costs are recruitment time, salary at whatever the senior machine learning market pays in your location, and the management overhead of a function your existing engineering leadership may not know how to evaluate. There is also a quieter cost: a team of one is not a team. Somebody has to cover holidays and incidents, so the realistic minimum for an assistant that customers depend on is two people who understand it.
In-house is right when conversation is close to your product rather than a support cost, when you expect to build several assistants rather than one, or when data sensitivity means the work genuinely cannot leave your organisation.
An AI development agency
An agency brings an assembled multidisciplinary team with delivery process already in place: engineers, data work, cloud architecture, quality assurance and project management, plus existing patterns for architecture review and security assessment. The advantage is time to production and the fact that somebody has made these mistakes already at their own expense.
The trade-offs are a higher day-one price, the risk of your account being staffed by whoever is free rather than whoever is best, and post-launch support that varies enormously between a retainer and a warranty period. An agency that has not built anything in your sector will also take longer to learn your domain than an internal hire would, and you pay for that learning at agency rates.
Agencies fit mid-market organisations that need a working system in a defined window, and larger organisations starting an automation programme where the first build sets the pattern for the next five.
Dedicated generative AI developers
The dedicated model places one or more engineers on your project for an extended engagement. They join your standups, learn your domain and your data, and stay long enough for the second and third iterations, which is where most of the value in a support assistant actually appears. You skip the recruitment cycle, you avoid the agency pattern of rotating staff, and the people who built the thing are the people who improve it.
This is the model we run most often at XOVO Technologies, and the honest description of its weakness is dependency. A dedicated engagement that ends abruptly leaves you in the same position as a departing in-house hire, which is why the handover artefacts in the ownership section matter more here than anywhere else. Ask for documentation and evaluation sets as deliverables during the engagement, not as an exit task.
It fits organisations that need production-grade capability without building a permanent function, and those treating conversational AI as an ongoing capability rather than a project with an end date.
Four ways to build a custom AI chatbot
| Hiring model | Day-one cost | Time to production | Who owns the IP by default | What dominates cost at 24 months | Where it fails |
|---|---|---|---|---|---|
| Freelancer | Lowest | Fastest to a prototype, slowest to a hardened system | The freelancer, unless an assignment clause says otherwise | Rework and replacement when the individual moves on | Breadth. One person rarely covers retrieval, integration, security and deployment |
| In-house team | Highest, paid before anything ships | Slowest, gated by recruitment | You, as employer, for work within the scope of employment | Salary, which continues whether or not the assistant changes | Single points of failure and holiday cover in the first year |
| Agency | High, concentrated in the build phase | Fast and predictable | The agency, unless the contract assigns it | Change requests and the support retainer | Domain learning billed at agency rates, and staff rotation |
| Dedicated developers | Moderate, spread across the engagement | Fast, with the second iteration included | Negotiated per contract, most often assigned to the client | The monthly engagement fee, which is visible and cancellable | Dependency on a partner, if handover artefacts are never produced |
The two right-hand columns are the ones buyers skip and later regret. The next two sections take them one at a time.
Who owns the prompts, the retrieval index and any fine-tune?
Ownership of a chatbot build is not one question. It is five, and a contract can answer some and silently leave the rest.
The five assets are the application source code, the prompt set and system instructions, the retrieval index together with the pipeline and chunking configuration that produced it, any fine-tuned model weights, and the evaluation data, which is the set of test conversations and expected outcomes that lets anyone verify the system still works. The last one is the most commonly forgotten and the hardest to recreate, because it encodes months of decisions about what a correct answer looks like.
Most contracts mention the first. Fewer mention the second and third. Almost none mention the fifth. The result is a handover where you receive a repository you cannot evaluate, so the only party who can tell whether a change made things worse is the party you were trying to leave.
The work-made-for-hire trap
United States copyright law does not do what most procurement templates assume. A work created by an independent contractor belongs to the contractor unless the creator is an employee acting within the scope of employment, or the work falls into one of nine enumerated categories that can be made a work for hire by written agreement. The US Copyright Office lists those nine categories in Circular 30 on works made for hire, revised August 2024: contributions to a collective work, parts of motion pictures or audiovisual works, translations, supplementary works, compilations, instructional texts, tests, answer material for tests, and atlases. Software is not on the list.
A contract that calls your chatbot codebase a work made for hire may therefore transfer nothing at all. The operative clause has to be a present assignment of rights. Plenty of freelance and agency agreements contain the former and not the latter, and the gap only becomes visible when somebody tries to sell the company or switch supplier. If you take one action from this article, it is to read the intellectual property clause of your existing chatbot contract and check whether the word "assigns" appears.
Prompts sit in an odd position. A prompt set is text, and the protectable value is usually in the specific wording and structure rather than the idea. Treat it as a deliverable and name it in the contract, alongside the system instructions and the guardrail rules, rather than assuming it travels with the code.
The retrieval index is your data, mostly
The index is derived from your content, which is yours, but the embeddings, the chunking configuration and the metadata schema are engineering artefacts created by whoever built them. Ask for three things by name: the ingestion and chunking code, the index configuration, and the ability to rebuild the index from source content in your own environment. Without the third, "you own the data" is true and useless, because rebuilding a retrieval system from a document folder and no configuration is most of a rebuild.
There is a regulatory tailwind here for cloud-hosted arrangements. Under the EU Data Act, applicable since 12 September 2025, providers of data processing services must remove obstacles to switching and export customer data in commonly used machine-readable formats, and from 12 January 2027 may not charge switching or data egress fees at all. That helps you get the data out. It does nothing about configuration, which is where the real switching cost sits.
Fine-tunes carry the base model's licence
If any part of your build involves fine-tuning an open-weight model, the base licence follows the derivative. Meta's Llama 4 Community License requires derivative model names to begin with "Llama" and requires prominent display of "Built with Llama", with a separate licence needed above 700 million monthly active users. Apache 2.0 models such as Qwen3-32B carry none of those conditions. For a white-labelled product or a model you intend to redistribute, that naming requirement is a product decision, not a legal footnote, and it needs deciding before the fine-tune runs rather than after.
Fine-tuning on a hosted provider raises a different question: whether the resulting weights are exportable at all. Some providers let you train an adapter you can only use inside their platform. That is a reasonable product design and a poor ownership position, and it should be priced as a switching cost rather than assumed away.
Ownership by hiring model
| Asset | Freelancer | In-house team | Agency | Dedicated developers |
|---|---|---|---|---|
| Application source code | Contractor's, unless expressly assigned in writing | Yours, as employer, within scope of employment | Agency's by default in many templates; assignment is negotiable | Usually assigned to the client, confirm the clause |
| Prompts and system instructions | Rarely named in the contract; assume unassigned | Yours | Often treated as agency methodology and retained | Name them as a deliverable and they transfer |
| Retrieval index and pipeline config | Often left on the freelancer's machine | Yours, if documented | Yours in output, theirs in tooling, unless specified | Yours, if handover artefacts are contracted |
| Fine-tuned weights | Depends on whose account trained them | Yours, subject to the base model licence | Depends on whose provider account was used | Train in your account and the question disappears |
| Evaluation sets and test conversations | Almost never delivered | Yours, if anybody built them | Rarely delivered unless requested | Request as a monthly deliverable, not an exit task |
| Cloud and provider accounts | Frequently the freelancer's personal account | Yours | Frequently the agency's | Insist on your own accounts from day one |
The pattern is consistent. Ownership follows whoever's account and contract the work happened in, not whoever paid for it. The fix is procedural rather than legal in most cases: run the build in your own cloud and model provider accounts, name every artefact in the statement of work, and require an assignment clause rather than work-made-for-hire wording. Our guide to hiring an AI agent development partner covers the contract conversation in more detail for larger agentic programmes.
What the four hiring models cost over 24 months, not three
Every vendor publishes a build price. Almost nobody publishes the two-year figure, which is the number that decides whether the project was worth doing. What follows is a model rather than a price list. We are not going to invent day rates or salaries, because they vary by an order of magnitude between markets and because a fabricated number would make the model less useful, not more.
Fill in your own figures for each variable. The value of the exercise is in seeing which term dominates, and it is usually not the one that dominated the procurement discussion.
The seven inputs
| Variable | What it is | Where your number comes from | What people get wrong |
|---|---|---|---|
| B, build fee | The one-off cost to get to production | The quote, itemised as in the section above | Treated as the total cost rather than the entry cost |
| M, monthly engineering | Retained engineering to fix, tune and extend after launch | The support line of the quote, or a fraction of an internal salary | Assumed to be zero for the first year |
| I, inference | Model API spend per month | Your own token measurement against published provider rates | Estimated from conversation count without measuring context size |
| H, hosting | Infrastructure, vector store and observability per month | Cloud and vendor pricing pages for your own configuration | Forgotten entirely, or confused with inference |
| O, internal ownership | The fraction of an internal person's time spent owning the system | Your own fully loaded employment cost, times that fraction | Counted as free because it is already on payroll |
| R, replacement | Cost of recruiting or re-engaging when the person who built it leaves | Your recruitment fee plus ramp time from your last senior hire | Priced at zero, which assumes nobody ever leaves |
| X, exit | Cost of moving the system to another party | Rebuild estimate for whatever the contract does not transfer | Only discovered at the point of leaving |
The 24-month total for any model is B + 24(M + I + H + O) + R + X. Three of those terms are recurring, two are contingent, and one is the number on the proposal.
How each model loads the formula
| Hiring model | B, build | M, monthly engineering | O, internal ownership | R, replacement risk | X, exit cost | Which term usually dominates |
|---|---|---|---|---|---|---|
| Freelancer | Lowest | Irregular and rate-based; often zero until something breaks | High, because architecture decisions have no second owner | High. One person, no redundancy | High if no assignment clause and no documentation | R and X, both invisible at signature |
| In-house team | Effectively salary during the build period | Continuous salary, whether or not work is needed | Highest, it is the whole model | Moderate, but expensive and slow when it happens | Lowest, the knowledge stays | Salary, across all 24 months |
| Agency | Highest single line | Retainer, or per-change billing | Low during build, rises sharply after handover | Low during contract, concentrated at its end | Moderate to high, depending on the IP clause | B plus change requests |
| Dedicated developers | Moderate, spread | Predictable monthly fee | Moderate, one internal owner is enough | Low while engaged, moderate if the engagement ends | Low if handover artefacts were contracted | M, which is at least visible and cancellable |
Three observations hold across most of the arithmetic we do with clients, and none of them depend on the specific rates you enter.
The build fee stops being the largest term somewhere in the first year for every model except the pure agency one. Twenty-four months of M, I, H and O added together usually exceeds B, which means a procurement process optimised entirely around B is optimising the smaller number.
O is the term that gets left out, and it is the term that sinks the in-house case when someone finally counts it. A system that customers depend on needs an owner with slack, not a volunteer with a full workload. If you cannot name that person, your real O is zero and your real risk is that nobody notices the assistant has been wrong for six weeks.
R and X are contingent, and contingent is not the same as unlikely over a two-year horizon. A freelancer engagement with no assignment clause and no documentation carries an X that can approach B, because moving means rebuilding. That is the entire argument for spending an hour on the ownership section before signing rather than a month on it afterwards.
Run the formula twice before you choose: once with your expected case, once assuming the person who built it is unavailable from month nine. The second run is the one that changes minds.
Bring the seven variables above to a working session and we will fill them in against your actual systems, your content volume and your market rates rather than a generic range. Book a scoping call and you leave with an itemised quote you can compare against anyone else's.
Should you build in-house or hire a chatbot development company?
Build in-house if you already have engineers who understand retrieval architecture, vector stores and orchestration, and if the assistant is close enough to your product that you want the capability permanently on staff. Hire a development company if you need it live in weeks rather than quarters, or if this would be the first system of its kind your team has built.
A middle route is worth considering more often than it is taken. Keep integration work in-house, where your engineers already know the systems and the authentication, and bring in a specialist for retrieval, evaluation and orchestration, which is the part with the steepest learning curve and the highest cost of getting wrong. That split also produces a natural handover, because your own engineers are in the code from week one.
The question of whether to license a platform instead of building at all is a different decision, taken earlier, and our piece on platform, agency or in-house build works through it properly. The next section covers the narrower version: you have decided to build, and here is when you should stop.
When not to build one
We sell custom builds. Here are the cases where commissioning one is the wrong call, stated plainly because the alternative is you discovering it in month four.
Your volume may simply be too low for the arithmetic to work. Published per-outcome pricing gives a usable benchmark. Fin, formerly Intercom, publishes $0.99 per outcome for resolutions, procedure handoffs and disqualifications, with a minimum of 50 outcomes a month, as checked on its pricing page on 12 September 2026. At that list rate, 500 resolved conversations a month costs about $495. Twenty-four months of that is roughly $11,880, which sits below the bottom of our own cheapest build tier before you have paid for any engineering time. The arithmetic only turns in favour of a build at volume: at 3,500 resolutions a month, the same list rate works out near $3,465 a month, and a $50,000 build fee is recovered in something over fourteen months on that comparison alone. Those are calculations on published list prices, not quotes, and your negotiated rate will differ.
Generic questions on standard systems are the second case. If the assistant needs to answer questions about shipping times and returns, and your commerce platform is one a vendor already integrates with, a platform product will do it this month. Helpdesk suites bundle this now: Zendesk's published plan pricing, checked on 12 September 2026, runs from $19 per agent per month on Support Team to $115 on Suite Professional billed yearly, with AI agents included across Suite and Support plans and billed by automated resolution. Paying for a custom retrieval pipeline to answer questions a bundled product already answers is an expensive way to own something.
The third case is that nobody will own it. A custom assistant is a system, and systems need somebody whose job includes them. If nobody can commit a few hours a week to reviewing conversation logs, your build will degrade into an expensive FAQ page within two quarters. A platform at least degrades on the vendor's schedule rather than yours.
Unready content is the fourth. Retrieval amplifies whatever is in the index. If your documentation is contradictory and no team owns resolving it, the build will surface that contradiction to customers at scale. Fix the content first. That work has value whether or not you ever build an assistant.
The last case is a deadline measured in days. No custom build of any merit takes ten days. If a board commitment or a launch date is driving the timeline, buy something now and build later with the conversation data the bought thing generates. That data makes the eventual build better and cheaper.
Two cases run the other way and are worth naming so the section is not one-sided. If the hard part of your problem sits on your side of the API, a non-standard warehouse system, an entity resolution problem, undocumented business rules, then a platform will struggle exactly where you need it most, and the build is justified. And if ownership of the conversational layer is strategically necessary, because it is a differentiator or because regulation requires the data to stay inside your estate, the ownership argument outweighs the arithmetic.
Platform choice carries its own risk, and it is worth naming rather than pretending otherwise. Salesforce announced on 15 June 2026 that it had signed a definitive agreement to acquire Fin for approximately $3.6 billion, stating that Fin serves more than 30,000 companies with AI agents resolving on average 76% of support volume end to end. Acquisitions are not automatically bad for customers. They do reset the roadmap, the pricing committee and the account team at the same time, which is a reason to read a three-year platform contract with the same attention you would give a build contract.
What every production chatbot needs on day one
Whether you are reviewing a build proposal or evaluating a platform, this is the capability list that separates something production-ready from something demo-ready. These are the defaults on every chatbot project we deliver.
- Human handoff that identifies the conversations needing a person and passes them across with full context attached, rather than dumping the customer into a queue to start again
- Multi-channel delivery across web chat, WhatsApp, email and internal messaging from one knowledge layer, rather than a separate configuration per channel
- Conversation memory within a session, so customers are not asked twice for an order number
- Sentiment signals feeding escalation priority, so a frustrated customer reaches a person sooner than a curious one
- Semantic search over the knowledge base rather than keyword matching
- An analytics view showing volume, resolution rate, escalation rate and the questions that failed
- An admin interface that lets a non-engineer update content and review answers
- Access control, encryption in transit and at rest, and audit logging of what the assistant read and when
- Action capability where it is justified, such as checking an order or opening a ticket, with each permitted action scoped explicitly
- Designed fallback behaviour for questions outside scope, which means a specific response and a specific route, not silence
Disclosure now belongs on that list for anyone with European users. Article 50 of the EU AI Act has applied since 2 August 2026 and requires that natural persons are informed they are interacting with an AI system, clearly and distinguishably at the first interaction, unless that is obvious from the context. Write the disclosure wording during conversation design, not during the pre-launch legal review.
Our own AI Chatbot product ships these as standard and, as its product page states, resolves up to 80% of customer queries without a human agent. For support operations that need to route across chat, email and voice in one thread rather than a single channel, the AI Support Architect handles that orchestration with the same escalation rules.
How do you keep an autonomous chatbot on-brand and inside its limits?
You keep it safe by making handoff the default for anything outside its confidence threshold, and by designing that threshold before launch rather than after the first complaint. The assistant answers what it can ground in your content and routes everything else to a person automatically: refund disputes, legal questions, anything where the customer is clearly upset.
On-brand is a retrieval problem more than a prompt problem. An assistant restricted to your approved content writes in your registered terminology because that is the only wording it has. Assistants that drift into generic customer service language are usually retrieving too little and improvising the rest, which is a tuning fault rather than a personality fault.
The security posture has moved on in 2026. The OWASP GenAI Security Project's 2026 Top 10 for LLM Applications, published on 3 August 2026, keeps prompt injection in first place and moves excessive agency up from sixth in the 2025 list to third. Excessive agency is the relevant one for anybody giving an assistant the ability to act: the risk is not that the model says something wrong, it is that it does something wrong with a permission it should never have held. Scope every tool call to the narrowest permission that satisfies the use case, and require human approval for anything that moves money or changes an account holder's access.
The same guardrail thinking applies whether the system is a single assistant or a multi-step agent pipeline. Our guide to agentic architecture and guardrails goes further into escalation thresholds, audit logging and approval steps for higher-stakes autonomous work.
What ongoing support should you expect after launch?
A chatbot needs monthly attention, not a warranty period. Conversation logs need reviewing to find question types the original content never covered. Prompts need adjusting as policies change. The underlying model version changes on the provider's schedule rather than yours, and behaviour shifts with it.
At XOVO Technologies we include managed operations and monitoring in chatbot engagements rather than selling it separately, covering uptime monitoring, monthly log review, retrieval and prompt updates when your documentation changes, and a route to the engineering team outside business hours. Whoever you hire, ask exactly what happens in month two: who reads the logs, how quickly an escalation gets triaged, and whether model or prompt updates are included in the fee or billed as changes.
Most teams track three numbers after launch. The share of conversations resolved without escalation. The share routed to a person, and how fast that routing happens. And satisfaction on the conversations the assistant resolved by itself. Watch them together rather than separately: if resolution climbs while satisfaction falls, the assistant is answering confidently in situations where it should be escalating, and the confidence threshold needs moving. Our analysis of customer service automation economics works through how those numbers translate into a cost per resolution you can defend in a budget meeting.
How does a chatbot connect to your website, CRM and support tools?
It connects through pre-built integrations where they exist and a custom API connector where they do not. An assistant that cannot see your CRM records, your helpdesk tickets or your order history can only answer generic questions, which is why integration work regularly takes longer than conversation design.
Three connection patterns cover most builds. Read-only retrieval, where the assistant queries a system for context and never writes back, which is the fastest to secure and the easiest to approve. Scoped write access, where a small number of explicitly permitted actions are allowed, such as creating a ticket or updating a delivery address. And event-driven triggers, where something happening in another system starts a conversation, such as a failed payment prompting a proactive message.
Authentication is where timelines slip. Every system has its own model, some require an administrator who is not in the project meetings, and enterprise single sign-on adds a review cycle that has nothing to do with engineering. Ask for the list of required credentials in week one rather than week five.
Our AI chatbot building and integration service handles this end to end, connecting the assistant to your website, Google Workspace or Microsoft 365, your CRM and your existing support stack, so a handoff to a person carries the full conversation rather than starting over. For the broader architecture question of how conversational systems fit an enterprise estate, our enterprise conversational AI guide covers the security model and the platform decisions around it.
Red flags in a chatbot proposal
Some checks apply regardless of which hiring model you choose.
If a vendor cannot tell you which specific engineer will do the work, you are buying a capacity promise rather than a team. Ask for names and ask what else those people are on this quarter.
If the contract says nothing about what happens after launch, the answer is nothing happens after launch. Month two support is the single most common gap between what a buyer assumed and what a contract says.
If the portfolio is all finished demos and no integration detail, ask how a past project connected to a real CRM or helpdesk, and what broke. A team that has been in production has a story about a rate limit, an authentication renewal, or a handoff that dropped context. A team that has not will describe the chat window.
If nobody will show you a real conversation log, including the times the assistant got something wrong and routed to a person, take that as an answer. Redacted logs are normal, absent logs are a signal.
And if the price looks low against the itemised list in this article, find out which line is missing before you treat it as a saving. It is usually testing, content preparation, or the assignment clause.
Where custom chatbot builds are heading
The architecture worth building in late 2026 assumes three things about the next two years.
Assistants act more than they answer. A support assistant handling a late delivery increasingly checks the carrier API, tells the customer what actually happened, applies a credit if the policy allows it, and updates the order record, rather than describing what a human would do next. That shifts the engineering centre of gravity from conversation quality to permission design, which is exactly where the OWASP ranking of excessive agency points.
Voice and text converge on one intelligence layer. Organisations that built separate telephone and chat systems are consolidating them, because maintaining two sets of policy logic produces two different answers to the same question. Our overview of AI voice agents for business covers what changes when the channel is a phone call.
Multimodal input becomes ordinary. A customer photographing a damaged item or a confusing statement line expects the assistant to read it. That is an indexing and evaluation problem as much as a model one, because an evaluation set built entirely from text questions tells you nothing about how the system handles an image.
None of that changes the decisions in this article. The hiring model still determines who can extend the system when the next capability arrives, and the ownership clause still determines whether you can take it with you. Those two choices outlast every model version you will run through.
Send us the quote you have, or the requirement you have not yet written a quote for. We will map it against the seven cost variables, the ownership checklist and the tier ranges above, and tell you honestly if buying a platform is the better answer. Start with a scoping session.
