How to Build a Chatbot: The Four Routes, Honestly Compared

The four routes at a glance

Read this as a shortlist, not a ranking. The right row is the one whose constraint column you can live with. Costs outside matram.ai's own prices are estimates for sanity-checking a quote.

The custom row is deliberately given in engineer-months rather than dollars, because a loaded engineering cost that is right 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 instead of sticker terms, the chatbot ROI calculator turns your ticket volume and handling time into what any of these has to save to justify itself.

Route 1: build it on a chatbot platform

This is the route most people searching for how to build a chatbot actually want, and it is the one where the word "build" is most misleading. You are not assembling anything. You are pointing an existing system at your content and deciding how it should behave.

Step 1: write down the twenty questions first

Before you open a single vendor's site, open your inbox, your live chat transcripts or your support queue and write down the twenty to thirty questions customers actually ask, in the words they actually use. Not the questions you wish they asked. This list is the single most valuable artefact in the whole project. It is your evaluation set on every route, it tells you whether a platform is good enough, and if you later hire developers it is a better brief than anything a discovery workshop will produce.

Step 2: choose a platform against your real constraints

Platforms in this category differ less on the core answering behaviour than their marketing suggests. Where they genuinely differ is pricing model, what happens when a conversation needs a human, which content sources they can read, and whether the plan you can afford removes their branding. Watch the pricing model especially: a flat monthly fee and a per-resolution fee behave very differently at ten times your current volume, and the cheaper one at today's volume is often the expensive one next year.

Step 3: connect your content

Every retrieval chatbot answers from source material, so this step decides how good yours will be. Most platforms crawl a website from a URL or a sitemap, and many also accept uploaded documents or connect to a knowledge base. Point it at everything relevant, then look at what it indexed. If your pricing lives only in a PDF that nobody has updated since last year, the chatbot will answer from last year. Content quality is the ceiling on chatbot quality, and no amount of configuration raises it.

Step 4: configure behaviour, not just appearance

Colours and the welcome message take five minutes. The settings that matter take longer: what tone it uses, what it does when it does not know the answer, when it offers a human, what it collects before handing over, and whether it is allowed to answer from general knowledge or only from your content. That last one is the difference between a bot that occasionally invents a refund policy and one that says it cannot find the answer and offers to fetch somebody.

Step 5: test it against your list, in the playground

Now paste in those twenty to thirty questions, one at a time, and read the answers properly. You are looking for three failure types: answers that are wrong, answers that are right but in the wrong voice, and answers it could not give because the content does not exist anywhere. The third type is the useful one. Each gap is a page you should write anyway, and writing it improves your public documentation at the same time as your chatbot. Expect to go round this loop two or three times before it feels right.

Step 6: embed it, then keep reading transcripts

Installation is a script tag in your site template, and on hosted site builders it is a field in the settings panel. That part takes a minute. What matters is the first two weeks after: read every conversation, note every question you did not anticipate, and fix the content. Launch is the start of the work, not the end of it.

For what this looks like in a specific business, the ecommerce chatbot guide and the small business chatbot guide cover the questions and escalation rules each tends to need.

When building one is not the answer

Four situations, in escalating order. In the first two you should not build anything at all. In the second two you probably need something, but writing and running it yourself is the wrong way to get it.

Stage one: answering them yourself is genuinely fine

Enquiries arrive in ones and twos. You read each one, you know the answer, you reply and move on. There is nothing here to automate, and a chatbot would not hand the time back anyway, because you would spend more of it writing the answers the bot needs and then reading what it told people. Automation pays on volume. Below a certain volume no arithmetic saves it, and none of the four routes changes that. Odd thing to say on a page like this one. It is still the first thing worth checking.

Stage two: friction starts, and the cheaper fix comes first

Now the same questions repeat and answering them has become a chore. The instinct is to build something. The better move is usually to write something. Take the twenty to thirty questions from the list above, put the answers on a page customers can actually find, link to it from your order confirmations and your contact form, and see what volume is left. Often what remains is small enough to live with. And you have improved your public documentation, which you had to do anyway, because a chatbot pointed at content nobody has written yet has nothing to say.

Stage three: the half-finished one becomes a liability

This is the stage that catches capable teams. Somebody wires up a prototype, it works, it goes on the site, and then that person moves to another project. Dependency updates stop. The index still holds the pricing page as it was before the last change. Nobody is reading transcripts, so wrong answers go unnoticed until a customer quotes one back at you in an email that starts "your website told me". A chatbot in that state is worse than no chatbot, because to a visitor it reads as an official answer. The maintenance that would have prevented it never reaches anybody's roadmap, because it does not look like work until it is overdue.

Stage four: the edge case the design cannot survive

Then comes the question your build was never shaped for. Where is my order. Has my plan renewed. Why was I charged twice. What does my contract actually say. Each of those needs identity for an anonymous visitor, an authenticated lookup into a system you own, a permission model, and a clear view of what a confidently wrong answer about somebody's money costs you. You can build all of that. But you have now crossed from a chatbot project into a product feature with an on-call rota attached, and the ceiling on a self-built chatbot is rarely the model. It is whoever has to keep it alive.

Route 2: build it in a no-code builder

No-code builders give you a canvas and you draw the conversation on it. It is a genuinely different skill from configuring a platform, and it produces a genuinely different bot: one that is excellent at sequences and poor at surprises.

The mental model is a flowchart. A node asks something or says something, branches send the conversation different ways depending on the answer or a keyword match, and variables carry information between nodes so the bot remembers what the customer said three steps ago. Many builders now also let you drop a generative step into a branch, which is worth understanding: those hybrid flows are usually the strongest thing this route produces.

The actual sequence

• Pick one job, not all of them. "Book a viewing" or "check an order" builds cleanly. "Answer customer questions" does not, because you cannot draw a branch for a question you have not thought of.
• Sketch the happy path on paper first: the shortest route from opening message to the outcome you want, with no detours. Build that, end to end, before you add anything else.
• Add the branches that matter, and be ruthless. Every branch is something you maintain forever, and most flows collapse under their own weight around the fortieth node.
• Write the fallback properly. This is what the bot says when nothing matches, and it is where most real conversations end up. "Sorry, I did not understand" is a dead end. Offering a human, or a menu of the three things it can do, is not.
• Connect the outcome to somewhere real: your calendar, your CRM, your inbox, or a webhook. A flow that captures a lead into a screen nobody checks has achieved nothing.
• Walk the whole thing as a hostile customer. Type nonsense. Change your mind halfway. Answer a yes-or-no question with a paragraph. Whatever breaks here breaks in front of customers.

The honest limitation is coverage. A flow answers exactly the questions somebody anticipated, phrased roughly the way they anticipated, and nothing else. That is fine, and often correct, when the wording of a reply carries legal or clinical weight, or when the interaction is a transaction rather than a question. It is the wrong tool when customers ask the same handful of things in dozens of different ways, which is what a support inbox mostly is. The rule-based versus AI chatbot comparison goes deeper on which failure mode you can tolerate, and the no-code builder guide covers the tools themselves.

Routes 3 and 4: frameworks, and writing it yourself

Both of these need a developer. The difference is how much of the plumbing already exists. A framework hands you retrieval, orchestration and connectors and asks you to wire them together. Writing it yourself means you own every piece, including the ones that are boring.

Route 3: a low-code framework

Frameworks such as Rasa, LangChain, LlamaIndex and Botpress sit between configuration and code. You install the framework, define your data sources, choose a model provider, write the glue that ties retrieval to generation, and deploy it somewhere. A competent developer can have something answering questions in days. What you gain over a platform is control: your own retrieval strategy, your own prompt logic, your own actions against internal systems. What you take on is that the framework is now a dependency you upgrade, and the deployment is now yours to keep running.

This route makes most sense when you have one specific requirement no platform exposes, and everything else about your use case is ordinary. It makes least sense as a hedge. Choosing a framework because it feels more serious than a subscription is how teams end up maintaining infrastructure to deliver behaviour they could have configured.

Route 4: writing it yourself

The architecture almost everybody converges on is retrieval-augmented generation, and it has five parts. You split your content into passages and store them in a vector index. When a question arrives you search that index for the most relevant passages. You send those passages plus the question to a language model with instructions about how to answer. You return the answer, ideally with a link to the page it came from. And you log the whole exchange so you can see what happened later.

The generation step is the smallest part, and it looks roughly like this. Treat the snippet as an illustration of the shape only. It is not production code: error handling, retries, rate limiting, streaming, logging, conversation history, citation checking and abuse protection have all been removed to keep it readable.

# ILLUSTRATIVE ONLY - not production code.
# The answering step of a retrieval chatbot, with everything
# operational stripped out for readability.

import anthropic

client = anthropic.Anthropic()

def answer(question: str, passages: list[str]) -> str:
    # `passages` are the top matches from your own vector search.
    context = "\n\n---\n\n".join(passages)

    message = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=1024,
        system=(
            "You answer questions about our product using only the "
            "source passages below. If they do not contain the answer, "
            "say so plainly and offer to pass the question to a human. "
            "Never guess at prices, policies or availability.\n\n"
            f"{context}"
        ),
        messages=[{"role": "user", "content": question}],
    )
    return message.content[0].text

A working prototype of this is a day or two of work, which is exactly why custom builds get underestimated. The distance between that prototype and something you would put in front of paying customers is months, and it is spent on the unglamorous half: chunking content sensibly, evaluating answers against a fixed question set every time you change a prompt, handling the conversation that goes wrong, escalating to a person, rate limiting, permissions, analytics, and an admin interface so a non-engineer can change an answer without filing a ticket. That last one decides whether your chatbot stays current after month three.

Build this way when you genuinely must: an on-premise or data-residency mandate, knowledge locked in a system with no API, an interface that is not a website, or a chatbot that is the product your customers pay for. Do not build it because it looks cheap. You are not buying software, you are adopting a service your team now runs forever. The build a chatbot from scratch walkthrough covers the pieces in more depth.

How long it really takes, and what it really costs

Both questions have the same answer underneath: the building is about a third of the work. Whatever route you pick, the content, the testing and the ongoing correction is the rest, and it is the part nobody schedules.

Where the calendar time actually goes

Take a typical mid-sized project on any route and the phases come out in roughly the same proportion. Deciding what the chatbot is for and gathering the real questions is a week. Preparing the content it will answer from, which means writing the answers that do not exist yet, is one to three weeks of somebody's time and runs in parallel with everything else. Building or configuring is anywhere from an afternoon to three months depending on the route. Testing and refining against real questions is one to three weeks. And then monitoring, which does not end.

Add those up and the build is around thirty per cent of the effort on a custom project and far less than that on a platform. This is why "how long does it take to create a chatbot" has such wildly different answers in different guides: they are measuring different slices. A platform is live in an afternoon and good in a fortnight. A custom build is demo-ready in a week and production-ready in three to nine months. The gap in both cases is content and testing, not code.

The step people skip

Testing with twenty to thirty real customer questions, written down before you start and re-run after every significant change, is the highest-return hour in the whole project. It converts a vague feeling that the bot seems fine into a list of specific failures you can fix. Teams that do this ship something that works. Teams that test by typing whatever comes to mind ship something that works on the questions that came to mind.

What it costs

A platform subscription is a published monthly number and the model usage is inside it. matram.ai is $29, $69 or $199 a month with unlimited team seats, and the trial runs for seven days without a card. A no-code builder is likewise a subscription, plus a real ongoing cost in your own time maintaining flows. Those are the easy ones.

For the developer routes, three costs continue after launch and are routinely left out of comparisons. Model API calls are the smallest: at published list rates, an answer built from a question plus a few thousand tokens of retrieved passages costs fractions of a cent, 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 OpenAI's gpt-5.4-nano at $0.20 and $1.25. Small, but permanent, and it scales with the volume you are hoping to grow. Hosting is modest. The real recurring cost is human: somebody has to update dependencies, migrate when the model you built on is superseded, and edit answers when your product changes.

As planning estimates only, a tightly scoped freelance build often lands somewhere between $3,000 and $25,000, and agency projects between $15,000 and $150,000 or well beyond, with a great deal of movement by market and scope. Treat those as numbers to pressure-test a quote with, not as market data, because no reliable public dataset exists. The chatbot development cost breakdown itemises where a bespoke budget actually goes, and our own pricing is exact because it is ours.

Which route fits your situation

Match your situation to a row rather than to a budget. The most common expensive mistake is picking a heavier route than the problem needs, and the second most common is picking a lighter one when a hard constraint rules it out.

If you land in the left-hand column, which most businesses do, the practical advice is to start on a platform and keep the option to leave. You are not locking yourself in: the artefact that matters is your content, and content moves. If you land in the right-hand column, run the numbers before you commit, because the cost that never appears in a proposal is the four to six months of not having a chatbot at all. The chatbot ROI calculator gives you a payback period, and the development services buyer's guide covers how to vet a firm if you are hiring.

The mistakes that cost the most time

These come up on every route, in roughly this order of expense. None of them are exotic. They are just the things that feel like details in week one and turn out to be the project in week six.

Building before writing

A chatbot cannot tell customers something you have not written down anywhere. Teams routinely spend weeks on the system and an afternoon on the content, then conclude the technology is disappointing. The fix is to inventory your answers first: for each of your twenty to thirty real questions, find the page that answers it. Every blank is content to write, and that work belongs to you on all four routes.

Skipping the fallback

What the bot does when it does not know is a bigger contributor to how it feels than what it does when it does. An unhandled dead end reads as broken; an honest "I cannot find that, shall I get someone?" reads as competent. Decide this deliberately, and decide who receives the handover before you switch it on.

Launching without an escalation path

Some conversations must reach a person: a complaint, an outage, a customer who has asked the same thing three times. If there is no route to a human, the chatbot becomes the thing standing between your customers and help, which is worse than not having one. Wire the handover into a shared inbox or your helpdesk before launch, not after the first complaint.

Paying for training when you mean retrieval

"We will train a custom AI model on your data" almost always means retrieval: searching your content for relevant passages and passing them to a general model. That is the standard architecture, and it is what platforms already do. Genuine fine-tuning is a large expense, needs redoing when the base model changes, and mainly shapes style rather than improving factual accuracy. If a proposal charges you for custom model training, ask precisely what is being trained and on how many examples.

Buying an agent when you need a workflow

"Agentic" is doing a lot of pricing work at the moment. Anthropic's working definition is useful for cutting through it: agents dynamically direct their own processes and tool usage, while workflows run models and tools through predefined code paths. Most things sold as agents are workflows with a chatbot in front, which is fine and often correct, but it should not carry an agent price. Ask exactly which tools the system may call and what it is allowed to do without a human approving it.

Treating launch as the finish line

The chatbot you launch is a first draft, and the first fortnight of real transcripts will teach you more than the whole build did. Put a recurring half hour in somebody's calendar to read conversations and fix what they reveal. A chatbot nobody reviews degrades quietly as your product changes around it, and the failure is invisible until a customer mentions it.

Choosing a heavier route to avoid switching later

Migration anxiety pushes people into custom builds they do not need. It is mostly misplaced. Retrieval chatbots consume content, not configuration, so what you invested in writing good answers transfers to anything. What does not transfer is a decision tree, which is an argument for starting light rather than heavy. Start on the smallest thing that could work, learn what your customers actually ask, and let evidence decide whether you ever need more.

What getting this wrong actually costs

None of what follows appears on an invoice, which is exactly why it gets left out of the comparison. These are the costs of picking the wrong route, and they land months after the decision that caused them.

The first is the weekend that became a quarter. A prototype comes together fast, and that speed is the trap, because everybody in the room quietly extrapolates day one across the whole project. What follows is chunking that has to be rethought, a relevance threshold that needs tuning against real questions rather than the ones you happened to try, an admin screen so somebody who is not you can correct an answer, and a testing pass nobody put in the plan. None of it is difficult. All of it is time, and it came out of whatever else you were going to ship that quarter. That is the real bill, and it is paid in work that never happened rather than money that left the account.

The second is ownership. Prototypes reach production because they demo well, and a demo has no maintenance schedule attached to it. So the bot sits on the site with nobody accountable for it, answering from an index that drifts further from your product every week. Then the model you built on is superseded and you inherit a migration you did not ask for and cannot postpone: re-test the prompts, re-check that it still refuses the things it used to refuse, work out which answers quietly changed. If you bought a subscription, that is the vendor's problem. If you built it, that is your Tuesday.

And the mistake runs in the other direction too, which this page would be dishonest to skip. Buying when you should have built means living inside somebody else's assumptions and finding out late that the one behaviour your business depends on is the one nobody exposes. Both mistakes are quiet in month one. Both are loud in month nine. So before you commit either way, ask the question that actually separates the four routes: not what will this cost to build, but who is looking after it in a year, and have they agreed to that yet?

Frequently asked questions

Sources

• 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.
• OpenAI API pricing - gpt-5.4-nano list pricing of $0.20 per million input tokens and $1.25 per million output tokens, accessed 20 July 2026.
• Anthropic, "Building effective agents" (19 December 2024) - The distinction used in the mistakes section between agents, which dynamically direct their own processes and tool usage, and workflows, in which models and tools are orchestrated through predefined code paths.