Custom Chatbot Development Services: What You Actually Get

Custom build vs configurable platform

These are the two things being compared. Read both definitions before the comparison table, because most disagreements about chatbot projects turn out to be two people using the word custom for different purchases.

Custom chatbot development

Custom chatbot development is building a chatbot as bespoke software you own, with your own retrieval pipeline, your own interface and integrations written to your systems rather than to a vendor's connector list.

A real custom build is an application. Somebody writes the ingestion and chunking, stands up a vector store, writes the retrieval and prompt layer, calls a model API, builds the chat interface, wires the integrations, adds logging and evaluation, and ships it into your infrastructure. That is a software project with a backlog, an on-call rota and a dependency tree, not a purchase.

What you get for it is genuine: the source code is yours, the deployment target is yours (including inside your own network, which matters for some regulated workloads), the interface can be anything you can design, and an integration with a forty-year-old internal system is a question of engineering effort rather than whether a vendor supports it.

What comes with it, whether you wanted it or not

• Security patching of every dependency you pulled in, for as long as the thing runs.
• Model churn. Providers deprecate and reprice models, and someone has to re-test your prompts and retrieval against the replacement.
• Direct model API bills that scale with usage, on top of hosting, vector storage and observability.
• Key-person risk. The engineer who understood the retrieval layer leaves, and the next one needs a month to be useful.
• Feature parity work. Everything a platform ships as standard (analytics, multi-language, escalation, exports) is a ticket on your board.

Examples: Agency-built RAG applications, In-house builds on LangChain or LlamaIndex, Bespoke assistants embedded in a product

Configurable chatbot platform

A configurable chatbot platform is pre-built software you train on your own content and shape through settings, prompts and APIs, reaching a custom-feeling result without owning any of the code.

The retrieval pipeline, the interface, the escalation logic and the analytics already exist and are maintained by the vendor. Your work is content and configuration: point it at your site, docs and knowledge base, write the instructions that set voice and boundaries, decide when it hands off to a person, and connect the systems that matter through an API or webhooks.

The output can be strongly specific to your business, because answer quality in a retrieval system is driven mostly by the quality and coverage of the source content, not by who wrote the retrieval code. That is the uncomfortable truth behind a lot of custom builds: teams commission bespoke engineering to fix a problem that was actually a documentation problem.

What you are giving up

• Code ownership. If the vendor disappears, you have your content and your exports, not a running system.
• The interface is themed, not designed. You control brand, placement and copy, not layout.
• Integrations are bounded by what the platform exposes. If the answer is no, it is no, and no budget changes it.
• Deployment is the vendor's cloud. On-premise and air-gapped are off the table.

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

What each route actually gives you

Rows one, three and four are the ones that decide real projects. Everything else on this table can be argued about; those three either apply to you or they do not.

The middle ground is real but expensive. Enterprise conversational-AI platforms will sell you private-cloud deployment and heavy customisation, and their public marketplace listings show what that costs: on AWS Marketplace in July 2026, an Ada annual package listed at $33,000 for 60,000 conversations and a NiCE Cognigy private-SaaS enterprise licence listed at $1,000,000 a year. None of Ada, Cognigy or Kore.ai publishes pricing on its own website, which tells you the shape of that sales process before you enter it.

When a custom build is the wrong purchase

You arrived here having already ruled out the generic option, so this section takes the opposite job. These are the four places people are standing when they commission a build they did not need, in order of how much it costs to be wrong.

Rung one: nothing is blocked, you just haven't tried

The most common one. The requirement got written from a demo of somebody else's product rather than from your own content, and no configured tool has ever been pointed at your documentation. So there is nothing to compare a build against. An afternoon inside a trial resolves more of this than a discovery workshop does, and it resolves it with evidence instead of opinion.

Rung two: something is blocked, and it turns out to be the content

Friction now. The answers coming back are vague, so the conclusion is that the software is not good enough. Usually it isn't the software. Answer quality in a retrieval system is driven mostly by the coverage and clarity of your source material, which means a bespoke pipeline reading the same thin pages produces the same thin answers at several times the price. Fix the pages. Re-test. Then look at what is genuinely left, because it is nearly always a shorter list than the one you started with.

Rung three: you build it, and the build now owns you

This is the rung where it stops being a cost and becomes a liability. The application exists. Dependencies need patching. The model it was tuned against gets deprecated on the provider's schedule rather than yours, and every feature a platform ships as standard is now a ticket on somebody's board. And the engineer who understood the retrieval layer is one resignation away from being unavailable. You did not buy a chatbot. You took on a service your team runs from now on, whether or not anyone has that written into their objectives.

Rung four: the blocker that only code answers

But some blockers are real, and the argument above simply stops. A written obligation that data cannot leave infrastructure you control is one. So is a proprietary system with genuinely no API in front of it, and so is an interface that has to live inside the product you sell rather than beside it. Nothing you configure will reach any of those, and every hosted platform including ours is out of the running. So read the three-question test below in both directions. It exists to stop you building unnecessarily, and equally to stop you configuring something that was never going to work.

Where the money goes on a custom build

The figures below are planning estimates, not survey data. No trustworthy public dataset of custom chatbot build prices exists, so treat these as a way to structure a quote rather than as evidence about the market. The column that catches people out is the third one: a custom chatbot is not a project that finishes.

The model bill is the line most quotes leave out, because the agency does not pay it. You do, at list price, from the moment you go live. In July 2026 the published rates per million tokens were $5 input and $25 output for Anthropic's Claude Opus 4.8, $3 and $15 for Claude Sonnet 4.6, $5 and $30 for OpenAI's gpt-5.6-sol, $1 and $6 for gpt-5.6-luna, and $1.25 and $10 for Google's Gemini 2.5 Pro up to 200k tokens. Those are list rates before batching or caching discounts, and they are not directly comparable between vendors, since the same answer consumes different token counts on different models. A platform subscription absorbs all of this into one number, which is worth something even before you count the engineering.

If you want to sanity-check a quote against what the chatbot is supposed to earn or save, put your own numbers into the chatbot ROI calculator, and read the chatbot development cost breakdown for how these workstreams get quoted in practice.

The three-question test

Answer these honestly. If all three answers are no, a custom build is probably overkill, and the money is better spent on the content the chatbot will be answering from.

1. Does a compliance obligation require the chatbot to run inside your own network?

Not "would we prefer it", and not "is our data sensitive". Is there a written obligation, in a regulation or a signed contract, that data cannot leave infrastructure you control? Some public-sector, defence, health and banking workloads genuinely carry that requirement, and it rules out every hosted platform including ours. If instead the requirement is encryption at rest, tenant isolation, GDPR handling and a guarantee that your data is not used to train models, hosted platforms meet that routinely and you should ask for the specifics in writing rather than build.

2. Does it need to read or write to a proprietary system that has no API?

A chatbot that only answers questions from documents rarely needs deep integration. A chatbot that has to quote a live price from a bespoke ERP, check stock in a warehouse system written in-house, or trigger an action in a scheduling tool with no external interface does. Check whether the system genuinely has no API before you accept this. Plenty of internal systems have an undocumented one, and a small integration layer in front of it is far cheaper than a bespoke chatbot around it.

3. Do you have a budget in the six figures and engineers who will still maintain it in two years?

Six figures is a planning threshold for sanity-checking a quote, not a researched market price, and it comes from adding up the workstreams in the table above rather than from any published dataset. The budget alone is also not the test. The second half is. A custom chatbot with no owner degrades quietly:

Dependencies go stale, the model it was tuned against gets deprecated, retrieval quality drifts as content changes, and nobody is reading transcripts. Projects that fail rarely fail at launch. They fail eighteen months later when the person who built it has moved on and there is no line in anyone's objectives for keeping it good.

Scoring it

• Three no's: configure a platform. Spend the difference on documentation coverage, which is what actually determines answer quality.
• Yes to question 1: you need a custom build or one of the small number of enterprise vendors offering private deployment. Hosted SaaS cannot help you.
• Yes to question 2 only: try a platform with a public API first and integrate from your side. That is often a few days of work instead of a few months.
• Yes to question 3 only: you can afford custom, which is not the same as needing it. Run a configured platform for a quarter first and let the transcripts tell you what is actually missing.

What matram.ai gives you, and what it does not

We are on the configurable side of this line and nowhere else. Here is the full picture, including the part that disqualifies us, because you will find it out in week two anyway.

What you get

• Training on your own content: crawl a URL, import a sitemap, upload PDFs or DOCX up to 10MB, paste text, or connect Notion, Google Drive, Dropbox, OneDrive, SharePoint, Box, Confluence, Gitbook, Zendesk, Freshdesk and YouTube.
• Every answer cited to the source page it came from, so a wrong answer points at content you can fix.
• Strict mode, which restricts answers to your approved content instead of the model's general knowledge.
• Lead capture with CSV export, and escalation to a human through a shared team inbox.
• 95+ languages without rebuilding anything, and an analytics dashboard with daily email summaries.
• A public API on Standard and above, so you can integrate from your side rather than waiting for a connector. See the API documentation.
• Channels: website widget in one line of JavaScript, plus Slack, Messenger, Crisp, Freshchat, Zendesk, Zoho SalesIQ and Google Chat. WhatsApp and HubSpot are not available yet.
• Workspace isolation via row-level security, encryption at rest, GDPR-ready handling, and your data is never used to train AI models.

What you do not get

This list is not a roadmap tease. If one of these is a requirement, we are the wrong purchase and you should stop reading here.

• No code ownership. You have your content, your exports and your configuration. You do not have a repository.
• No fine-tuned foundation models. Answers are grounded in your content through retrieval, which is the right approach for the large majority of support and sales use cases, but it is not the same thing as a model trained on your data.
• No on-premise, private-cloud or air-gapped deployment. It runs in our cloud, full stop.
• No fully bespoke chat UX. You control colours, copy, placement and behaviour. You do not control the layout, and you cannot embed it as a native component inside your own application shell.
• No hardware, kiosk, IVR or in-store device integrations.
• No compliance certifications to point at. We are not SOC 2, ISO 27001, HIPAA or PCI DSS certified, and if your procurement process requires one of those, that is a hard stop.

Pricing is flat and public: $29 a month for Basic (1 chatbot, 2,000 messages, 3 data sources), $69 for Standard (5 chatbots, 5,000 messages, 25 sources, all channels, public API, branding removed), $199 for Pro (20 chatbots, 20,000 messages, 100 sources, priority support). Enterprise sits above those and is quote-based rather than published, with custom volume limits and invoiced billing, so you contact sales for a number. Team seats are unlimited on every plan. The trial is seven days and takes no card. Full detail is on the pricing page and the features page.

If you want to see what deep configuration looks like against a specific use case before deciding, the SaaS chatbot and ecommerce chatbot pages walk through the setup end to end, and the Intercom alternative comparison covers the case where you are replacing an incumbent rather than starting fresh.

If you do go custom, how to brief it

Assume you scored a yes. The difference between a custom build that lasts and one that gets quietly switched off is almost entirely in how the work was scoped, not in who wrote the code.

Decide whether you are buying a workflow or an agent

Anthropic's engineering team draws a line that is worth stealing for your brief: workflows are "systems where LLMs and tools are orchestrated through predefined code paths", while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks". Most business chatbots should be workflows. Agentic autonomy is harder to test, harder to constrain and more expensive to run, and it is frequently sold to buyers who described a workflow. Write which one you are buying into the statement of work.

Put these in the contract, not the kickoff deck

• Repository ownership and licence terms, in writing, including any agency-owned framework code the build depends on.
• Which model provider and model version, and who pays the API bill during and after the build.
• An evaluation set. A named list of real questions with expected answers, plus the pass rate the build must hit before you sign it off.
• A grounding requirement: answers cite the source document, and the system says it does not know rather than guessing.
• Handover terms. Runbook, architecture notes, and a named person on your side who can deploy it.
• The maintenance arrangement for year two, priced, before you sign year one.

Watch for configuration sold as engineering

A meaningful number of "custom AI chatbot development" proposals are a platform subscription with a wrapper on top and a five-figure margin. That is not automatically a bad deal, since somebody has to do the content and configuration work, but you should know which one you are buying. Two questions settle it: which parts of this do we own, and what happens to it if you stop trading? If the honest answer is that the platform keeps running and you keep your content, you are buying configuration, and you can price it against doing that yourself with a no-code chatbot builder.

The related read for the wider version of this decision, including agency selection and typical engagement models, is the AI chatbot development services guide.

What it costs to have been wrong about this

None of this appears on an invoice, which is exactly why it never makes it into the comparison you are doing today.

Say you commission the build and, a year in, you conclude you should have configured something instead. The money is the visible part and the least of it. The harder loss is calendar: the months during which the problem you set out to solve stayed unsolved, your team kept answering the same questions by hand, and the transcripts that would have told you what customers actually ask were never produced, because there was nothing live to produce them. You cannot go back and generate that data retroactively.

Then there is what you are holding at the end. A codebase with a dependency tree, written by people who are not on your payroll, in a shape only they have ever worked in. While they are still trading and still responsive, that is a supplier relationship and it is manageable. When they aren't, it is an asset nobody at your company can safely change, which in practice means it stops changing at all. And a chatbot that stops changing goes stale on exactly the same schedule your product does.

When you eventually replace it, you do the content work twice. Every document prepared again for whatever comes next, every integration rewritten, every stakeholder walked through it a second time, and the budget spent inside a company that has already watched one chatbot project underdeliver. So the question worth sitting with before the statement of work is signed is not what this costs. It is: if this is the wrong purchase, what will we have to redo, and who here will still be around to redo it?

Frequently asked questions

Sources

• Anthropic, "Building effective agents" (19 December 2024) - The workflow versus agent distinction used for scoping a custom build.
• Anthropic model pricing - Claude Opus 4.8 and Sonnet 4.6 list prices per million tokens, 20 July 2026.
• OpenAI API pricing - gpt-5.6-sol and gpt-5.6-luna list prices per million tokens, 20 July 2026.
• Google Gemini API pricing - Gemini 2.5 Pro list price per million tokens up to 200k tokens, 20 July 2026.
• AWS Marketplace vendor listings - Ada annual package at $33,000 for 60,000 conversations and the NiCE Cognigy private-SaaS enterprise licence at $1,000,000 per 12 months, accessed 20 July 2026.