AI Chatbot Development Services: An Honest Buyer's Guide

The four ways to get an AI chatbot

These are not four price points for the same thing. They produce different artefacts, transfer different risks, and leave you with different obligations five years later.

Chatbot development agency

A chatbot development agency is a firm that takes a brief, assigns a team of designers and engineers, and delivers a bespoke chatbot you own the code to.

A typical engagement puts a project manager, a conversation designer, one or two engineers and a part-time QA tester on your account for three to six months. You get discovery workshops, a statement of work, a design phase, a build, a testing round and a handover. Contracts come as fixed bids against a written scope, or time and materials against an hourly rate, and the difference between those two matters more than the headline number.

What you are actually buying is capacity and accountability, not secret technology. Almost every agency builds on the same publicly available model APIs you could call yourself. The value is that somebody else does the integration work, carries the delivery risk, and can be held to a date.

What to watch

• Nobody publishes rates, so you cannot benchmark a quote without collecting two or three of them.
• The scope you sign in month one is the scope you get. Everything after that is a change order.
• Delivery ends. Maintenance does not, and it is usually a separate retainer.

Freelance chatbot developer

A freelance chatbot developer is a single contractor who builds to a defined specification for a fraction of an agency fee and none of the institutional backup.

For a narrow, well-specified build this is often the best value on the list. One competent engineer with a clear brief can put a retrieval-based chatbot into production in weeks. The economics are good because you are not paying for a project manager, an account director or a sales cycle.

The risk is concentration. There is one person, no bench, no handover process by default, and no continuity if they take a full-time job in month four. If you go this route, insist that everything lives in your repository and your cloud accounts from day one, not theirs.

In-house build

An in-house build means your own engineers assemble the chatbot from model APIs, a vector store and your existing systems, and own it permanently.

The components are commodity now. A model API, an embedding model, a vector index, a retrieval layer, a chat interface, logging and an admin view. A capable team can stand up a working prototype in days. The distance between a working prototype and something you would put in front of customers is where the months go, and it is spent on the unglamorous parts: evaluation, guardrails, permissions, rate limiting, analytics, escalation and the admin tooling non-engineers need to change an answer.

Build in-house when the chatbot is part of the product you sell, or when it touches systems no vendor will ever integrate with. Do not build in-house because it looks cheap. You are not buying software, you are adopting a service your team now runs forever.

Examples: OpenAI API, Anthropic Claude API, Google Gemini API, pgvector

Configurable SaaS platform

A configurable SaaS chatbot platform gives you the same retrieval-and-generation architecture as a custom build, already assembled, with the configuration exposed as settings rather than code.

You point it at your website, help centre or document store, set the tone and escalation rules, paste a script tag, and it is live. The architecture underneath is the same one an agency would build for you. What you give up is control over the parts you probably were not going to change anyway, and what you get back is that somebody else handles model upgrades, uptime, and the fact that the state of the art moved again last quarter.

Pricing splits into two camps. Small and mid-market tools charge a flat monthly fee, matram.ai being $29, $69 or $199 a month. Enterprise platforms mostly do not publish rates at all, and the ones visible through marketplace listings run from tens of thousands to a million dollars a year. Fin, formerly Intercom, prices per resolved outcome at $0.99 with a fifty-outcome monthly minimum, which is a genuinely different model worth understanding before you compare anything.

Examples: matram.ai, Fin (Intercom), Zendesk AI agents, Tidio Lyro

The four routes compared

Read the cost column as a range for sanity-checking a quote, not as market data. There is no credible public dataset of custom chatbot build prices, and these figures move substantially with your country, your integration list and how much of the content work your own team absorbs. matram.ai's prices are exact because they are ours.

The in-house row is deliberately given in engineer-months rather than dollars, because a loaded engineering cost that is accurate in Manchester is wrong in San Francisco by a factor of three. Multiply by your own number. If you want the comparison in payback terms rather than sticker terms, the chatbot ROI calculator takes your ticket volume and handling time and works out what any of these routes has to save to justify itself.

When hiring a development firm is the wrong move

Saying most buyers should configure rather than commission is easy and, on its own, useless. What you need is a ladder, so you can find the rung you are actually standing on. Three of these four rungs end with you not hiring anybody.

Rung one: nothing is broken, so buy nothing

A few customer questions a week, answered by whoever knows the answer, between other work. Nothing is broken. A chatbot of any kind is net effort here, because somebody has to write the source content and then keep reading the transcripts, and at that volume the reading costs you more than the replying ever did. Fix your contact page. Write the answers people keep asking for and put them on your site where both search engines and humans can reach them. That is not a consolation prize. It is the same content work every route on this page depends on, done early, and it makes whatever you buy later work better.

Rung two: the friction is real and a product already covers it

Replies slip to the next morning. One person is the bottleneck, and the questions piling up are ones your help centre answers already. This is the exact point at which most agency briefs get written, and most of those briefs describe a purchase rather than a project. An agency will build you a retrieval chatbot over your own documentation, which is the default behaviour of every product in the category. You'd be paying for delivery capacity, not for capability you cannot otherwise get. Configure something first and watch what it gets wrong on your content. An afternoon of that tells you more about your requirements than a discovery workshop will, and it costs you nothing you would not have spent anyway.

Rung three: you commission the build, and the content problem comes with it

Here it stops being a cost and becomes a liability. The engineering is competent, the system ships, and the answers are still thin, because the source material was thin and no clause in a statement of work repairs that. Now you own an application with a dependency tree, plus the same documentation gap you started with and a retainer to keep paying for it. The tell is easy to miss at the time: nobody in the kickoff meeting asked to see your content before quoting on it.

Rung four: the requirement no configuration reaches

But there is a point where all of that stops applying. The bot has to read a live price out of a bespoke ERP with no interface on it. Or a signed contract says the data cannot leave your network. Sometimes what you are building is not a widget on a website at all: it is a kiosk in a shop, or a voice line on telephony somebody else owns. None of that is a content problem and none of it is a settings screen. So when you get here, stop pressure-testing platforms, go and hire someone, and use the vetting section further down to do it properly.

What an agency engagement actually contains

Proposals compress all of this into one line and one date. Here is what the months are really spent on, so you can see which phases you could shorten and which ones are your own team's work rather than the agency's. Durations are estimates for a mid-sized build, not contractual norms.

Notice how much of that is not engineering. Discovery, design, content and sign-off routinely account for more calendar time than the build. It is also the part that transfers cleanly: if you do the content and question inventory before you talk to anybody, you shorten the engagement and improve the result whichever route you pick.

The costs that never appear in the proposal

A quote covers delivery. These are the things that arrive after delivery and do not stop.

Maintenance is a permanent line item

Custom software does not sit still. Dependencies age, APIs deprecate, your product changes and the answers go stale. Agencies price this as a monthly retainer, usually quoted as a percentage of the build. Ask for that number before you sign the build, not after. Nobody publishes retainer data either, so treat any multiple you are quoted as an estimate, but add three years of it to the build price yourself before you compare routes, because it is the figure most likely to be missing from the comparison you are making today.

Model costs are yours forever

Every answer a retrieval chatbot gives is a model call: your question plus several thousand tokens of retrieved passages in, a few hundred tokens out. At published list rates that is fractions of a cent per answer, with Anthropic's Claude Haiku 4.5 at $1 per million input tokens and $5 per million output, Google's Gemini 2.5 Flash-Lite at $0.10 and $0.40, and the larger models an order of magnitude above those. Small, but permanent, and it scales with the volume you were hoping to grow. On a SaaS platform this is inside the subscription. On a custom build it is a bill you now receive.

Model churn

The model you build on in month one will be superseded before your warranty expires. A platform absorbs that migration for you. A custom build makes it a change request, and prompt behaviour rarely transfers cleanly between model versions, so somebody has to re-test the whole thing.

Handover quality

The difference between a good handover and a bad one is worth more than the discount you negotiated. A bad handover means undocumented prompts, credentials in one person's password manager, and no interface for a non-engineer to change an answer, which means every future content edit is a billable ticket. Put documentation, repository ownership and an admin interface for non-technical staff in the statement of work as deliverables, with acceptance criteria.

Scope creep, in both directions

Fixed-bid contracts push both parties toward the letter of the scope. You will discover things in week six that you could not have known in week one, and each one is a change order at a rate you did not compete on. Reserve a contingency of a meaningful fraction of the project value and assume you will spend it.

Four to six months of not having a chatbot

This is the cost nobody puts a number on and it is often the largest. Every week of the build is a week your customers wait on email replies and your team answers the same question by hand. Where the goal is to answer routine questions from existing documentation, that wait buys you very little that a configured platform would not have given you in an afternoon. A defensible plan is to run a platform during the build, both because it holds the line and because the transcripts it produces are the most useful requirements document you will ever hand your developers.

When custom development is genuinely the right call

There are real cases where no platform will do, and if you are in one of them you should stop reading vendor comparisons and go hire someone. There are also five reasons people commonly give that do not survive contact with a modern platform.

If you land in the right-hand column, run the numbers before you take a meeting. The chatbot ROI calculator turns your ticket volume into a payback period, and the chatbot development cost breakdown itemises where a bespoke budget actually goes. For sector-specific patterns, the SaaS chatbot guide and the small business chatbot guide cover what each typically needs, which is usually less than a proposal assumes.

How to vet a chatbot development company

If you are hiring anyway, this is the part that decides how the project goes. The signals below are about process and honesty, not portfolio gloss, because portfolios are marketing and process is what you actually buy.

Green flags

• They ask what documentation you already have before they ask what your budget is. Content quality determines how well any chatbot performs, and a firm that leads with it understands the work.
• They will show you a real transcript from a system they built, including the conversations that went badly, rather than a demo video.
• They name the model they intend to use and say what happens when it is deprecated. Vagueness here means either inexperience or a markup they would rather you did not see.
• They propose a small paid discovery phase with a written deliverable, so you can leave after four weeks with something useful if the fit is wrong.
• Source code, prompts and credentials are yours in writing from day one, in your repository and your cloud accounts.
• They tell you which parts of your brief a platform would handle, and scope only the rest. A firm willing to shrink its own contract is a firm you can believe on the other numbers.

Red flags

• "We will train a custom AI model on your data." Ask directly whether they mean fine-tuning or retrieval. It is nearly always retrieval, which is standard, and describing it as custom training is a pricing device.
• "Agentic" with no description of what tools the system calls or what it is allowed to do unsupervised. Anthropic's working definition is useful here: agents dynamically direct their own processes and tool usage, while workflows follow predefined code paths. Most things sold as agents are workflows. Gartner coined the term "agent washing" in June 2025 for exactly this, and found only around 130 of the thousands of vendors claiming agentic AI were genuine.
• A deflection or resolution percentage promised before anyone has looked at your content. That number is a property of your documentation, not of their software, and nobody can forecast it from a sales call.
• A fixed bid on a scope nobody has written down. Either the price is padded to cover the unknown, or the change orders start in week three.
• No named engineers, or a discovery call with people you will never work with again. Ask who is actually assigned and for how many hours a week.
• Ownership of the code, the prompts or the trained artefacts left ambiguous in the contract. Ambiguity here always resolves in their favour later.

One last question worth asking every firm on your shortlist: what would you do if my budget were a tenth of this? A good answer describes a platform, names one, and explains what you would lose. A bad answer is that it cannot be done. If you want to see what that tenth-of-the-budget option looks like in practice, the no-code chatbot builder guide and the Intercom alternatives comparison cover the two ends of the platform market.

What getting this decision wrong actually costs

Not the line items. The things that are already gone by the time you realise the decision was wrong.

Suppose you commission the build and it turns out you never needed one. The invoice is the smallest part of what you lost. You spent a stretch of calendar time that cannot be bought back, and through all of it your customers kept waiting on email replies while your team kept answering the same question by hand. Nothing brings it back. A refund covers the money and none of the rest.

Then the relationship becomes the thing you actually depend on. Once the system exists, the people who wrote it are the only people who understand it, and every change goes through them at a rate you are no longer in a strong position to negotiate. That is fine while they are good and responsive. It stops being fine when the engineer who built the retrieval layer moves on and the firm sends somebody who has never opened your repository. You did not buy software. You took on a dependency, and you renew it every time you want a wording change.

And if the thing eventually gets switched off, you do the work twice. The content has to be prepared again for whatever replaces it, the integrations rewritten, the team taught a second interface, and you spend that second budget inside an organisation that has already watched one chatbot project underdeliver. Patience is a budget too, and you only get to spend it once. So before you sign, ask a question with more predictive power than can we afford this: if this turns out to be the wrong purchase, how long would it take us to find out, and what would we still be holding when we did?

Frequently asked questions

Sources

• Anthropic, "Building effective agents" (19 December 2024) - The definitions of agents (LLMs dynamically directing their own processes and tool usage) and workflows (LLMs and tools orchestrated through predefined code paths) used in the vetting and FAQ sections.
• Gartner press release, 25 June 2025 - The term "agent washing" and the finding that only around 130 of the thousands of vendors claiming agentic AI capability were assessed as genuine.
• Anthropic model pricing - Claude Haiku 4.5 list pricing of $1 per million input tokens and $5 per million output tokens, accessed 20 July 2026.
• Google Gemini API pricing - Gemini 2.5 Flash-Lite list pricing of $0.10 per million input tokens and $0.40 per million output tokens, accessed 20 July 2026.
• Fin (formerly Intercom) pricing - Outcome-based pricing at $0.99 per resolved outcome with a 50-outcome monthly minimum, accessed 20 July 2026.
• AWS Marketplace vendor listings - Published annual contract prices for enterprise conversational platforms, ranging from tens of thousands of dollars a year to $1,000,000 for a private-SaaS enterprise licence, accessed 20 July 2026. Cognigy, Kore.ai and Ada do not publish rates on their own sites.