Build vs Buy an AI Chatbot: How to Choose for Your Website

The build vs buy AI chatbot decision mostly comes down to one question: where do the answers live? If your chatbot mainly needs to answer what's already on your website, buy one. If it needs data from your own systems, such as orders, bookings or account details, or you need full control over where conversations are stored, build it, or at least build the part that touches your data.

I'm a freelance developer who builds custom web apps, so I have a stake in the "build" side. That's why this guide is just as clear about when building is a waste of money.

The short answer

My rule of thumb: if a support agent could answer most questions by looking at your website, buy. If the agent would need to log into one of your systems to answer, a hybrid or custom build is the right track.

If you only get a handful of inquiries a month, fix your FAQ page first. A chatbot can't answer questions your content doesn't cover. And if you've already built a chatbot prototype yourself with an AI tool, you're facing a different problem: getting a vibe-coded prototype ready for real users.

Buying: live in days, but you pay per conversation

An off-the-shelf chatbot goes on your site with a small script. You point it at your pages, help articles or PDFs, and it answers from them using a large language model behind the scenes. The better ones add an inbox where a human can take over, plus reporting on what people ask.

The pricing model matters more than the headline price:

• Intercom Fin costs $0.99 per "outcome", according to Intercom's pricing page. An outcome counts when the customer confirms the issue is solved, doesn't ask for more help after Fin replies, or when Fin completes a workflow (which, per Intercom, includes handoffs). Agent seats come on top, from $29 per seat per month billed annually.
• Chatbase sells bundles of message credits, from $40 a month for 700 credits to $500 for 15,000, according to Chatbase's pricing page.

Paying per outcome sounds fair, but read the definition closely: a customer who doesn't ask for more help may simply have given up. And the bill grows with usage. At 2,000 billable conversations a month, that's just under $2,000 for the AI alone, or roughly $24,000 a year before seats. Run the numbers at next year's expected volume, not this month's.

When an off-the-shelf chatbot is the wrong choice

• The answer depends on data about the individual customer, like order status, account balance or their next booking, and the tool can't fetch it securely from your systems.
• You need to document exactly where conversations are stored, for how long and by whom, and the vendor's chain of sub-processors doesn't fit your requirements.
• The chatbot is part of your own product, and your customers should experience it as yours rather than as an embedded tool with someone else's rules.
• Your volume is high enough that per-conversation fees exceed what it would cost to run and maintain your own.

Building on your own data: what a custom chatbot involves

A custom chatbot almost never means training your own model. It usually means RAG (retrieval-augmented generation): the system finds the relevant passages in your content and sends them to a language model through its API, with instructions to answer only from them.

A production-ready build usually has six parts:

1. Sources: your website, help articles, product data and, where relevant, data from your systems for the logged-in user.
2. Search: your content is split into chunks and indexed so the right passages can be found in a fraction of a second.
3. Model: OpenAI, Anthropic (Claude), Mistral or Google, called through their API.
4. Rules: what the bot may answer, what it should refuse, and when it hands over to a person.
5. Logging: what was asked, which sources the answer drew on, and what the user was told.
6. Handover: email, a ticket in your help desk, or live chat with your team.

Most of the work is ordinary software development: access control, integrations and testing. The model call itself is the smallest part. I cover the wiring in the guide to adding an LLM API to an existing app.

What it costs to build and run

As a rough estimate that depends heavily on your data: a scoped chatbot answering from your own pages and documents, with logging and email handover, is typically 40-100 hours of development. Pulling in data from your systems for logged-in users usually means 120-250 hours. At senior freelance rates in Denmark of about €105-160 an hour, that's roughly €4,000-16,000 and €12,500-40,000 respectively, excluding VAT.

Running costs are model usage, hosting and maintenance. With smaller models, usage is often a few cents per conversation, but models get retired and your content changes, so budget time every month. The post on estimating LLM API costs shows how to work out the usage side.

When a custom build is the wrong choice

• The bot only needs to answer what's already on your website. You'd be paying to rebuild a product that exists.
• Nobody on your team has time to own it: reading logs, fixing sources, deciding what counts as a wrong answer. An unowned chatbot gets worse every month.
• You don't know yet whether customers will use chat. Trial an off-the-shelf tool for a couple of months first to collect real questions.
• The budget doesn't stretch to ongoing maintenance. Then a vendor that keeps the models updated is the honest choice.

In all four cases, my advice is not to hire a developer for it, and that includes me.

The hybrid: buy the chat window, build the data access

Several off-the-shelf chatbots can call an API you provide, for example to look up an order from an order number and email address. You get the vendor's chat widget, inbox and reporting, while your data stays in your own system and you decide exactly what can be fetched.

A hybrid works well when you already use a help desk with AI and only need a few actions that touch your data. It works badly once the list of actions grows. You end up paying for both a subscription and development, with logic split across two places.

Whichever route you take, securing that API is your job. The bot should only be able to fetch the current customer's own data, and only what it needs to answer. Users can try to talk the bot into fetching someone else's data, so access control has to live in your API, not in the bot's instructions.

GDPR and the EU AI Act apply either way

People type names, email addresses, order numbers and sometimes health details into a chat window, even when you don't ask for them. That makes the chat log personal data from the first message, and GDPR generally applies when you serve people in the EU, wherever your company is based.

• Data processing agreement: you need a DPA with the vendor and a clear list of its sub-processors, including the model provider.
• Transfers outside the EU: many vendors and models run in the US, which requires a valid transfer mechanism. OpenAI offers a European data residency region for its API, where data for most endpoints is processed and stored in the EEA and Switzerland, though it requires separate approval. According to OpenAI's documentation on API data, API data isn't used for training unless you opt in.
• Retention: decide how long conversations are kept and state it in your privacy policy.
• EU AI Act: under Article 50 of the AI Act, people interacting directly with an AI system must be told it's an AI, at the latest at the first interaction, unless it's obvious. This has applied since 2 August 2026.

The Article 50 duty formally sits with the provider of the AI system. If you build the chatbot yourself, that's you. If you buy one, check that the widget discloses it, and say it plainly in your welcome message anyway.

This isn't legal advice. If the chat could end up handling sensitive data, talk to a privacy lawyer before launch. I go deeper on what you can send to OpenAI and Claude under GDPR.

Quality control: making sure the bot gets it right

In 2024, Air Canada was ordered to compensate a passenger after its website chatbot gave wrong information about bereavement fares. The airline argued the chatbot was responsible for its own answers. British Columbia's Civil Resolution Tribunal rejected that: the chatbot is part of the website, and the company has to take reasonable care that its information is accurate, as McCarthy Tétrault's summary of the case explains. It's a Canadian case, but the principle travels well: what your chatbot says, you say.

That holds for bought chatbots too. Here's how I'd test one before launch and while it's live:

1. Collect 50-100 real questions from email, phone and chat, and write the correct answer for each.
2. Run them through the chatbot and review the answers. Flag anything wrong, vague or made up.
3. Make the bot show its source, and have it say "I don't know" and hand over to a person when there isn't one.
4. Lock down the risky topics. Prices and terms should be quoted from the source or linked, and the bot shouldn't promise refunds, discounts or anything legal.
5. Rerun the test set every time you change sources, instructions or the model.
6. Read a sample of real conversations every week for the first few months, and add new questions to the test set.

With a custom build, the test set can run automatically on every change, and you can log which sources each answer used. With a vendor, ask about testing and logging before you sign.

Next steps

Start with the questions, not the technology. Pull your 50 most common inquiries and sort them into two piles: those your website can answer, and those that need data from your systems. If the first pile is bigger, trial an off-the-shelf chatbot for a month. If the second is bigger, or the chatbot has to be part of your product, it's a development project.

A chatbot is also just one way to use language models. Often you'll get more from AI features that classify requests or fill in fields inside your app, where nobody has to type to a bot at all.

If your chatbot needs to live inside a web app or platform with logins and your own data, see how I work on custom web apps and platforms. You deal directly with me as the developer writing the code, and you own the code from day one.

Frequently asked questions

Can an AI chatbot handle several languages?+

Yes. The major models handle English, German, French and the Scandinavian languages well enough for customer support, and they usually reply in the language the user writes in. The weak spots are domain terms, product names and local rules like VAT or payment terms. If you serve several markets, build a test set per language rather than assuming quality carries over from English.

Will an AI chatbot replace my support team?+

No, but it can take a share of the repetitive questions and free your team for the hard cases. Complaints, judgment calls and unhappy customers still belong with a person, and the route to a human should be easy to find. A chatbot that traps customers in a loop costs you more in goodwill than it saves in time.

Which language model should I use for a custom chatbot?+

Use the cheapest model that passes your test set. For a bot that answers from your own content, smaller models are often good enough and faster. If you want data to stay in the EU, look at OpenAI's European region or a European provider like Mistral. Either way, build it so the model can be swapped without rewriting everything else.

How do I keep the chatbot's answers up to date?+

Have the chatbot read from the same pages and data as your website, so there's no separate copy to remember. In a custom build, content can be re-indexed automatically whenever a page changes. With a vendor, check how often it re-crawls your site.