How to Build a Custom AI Chatbot with ChatGPT or Claude

“Build a custom AI chatbot” describes four genuinely different projects. One takes twenty minutes and no code. One takes a fortnight and a developer. They are all called the same thing, and picking the wrong one is the expensive mistake — not because the build fails, but because you spend a month on something a Custom GPT would have done in an afternoon, or you ship a toy where the job needed a real system.

So this starts with which of the four you actually want, then covers the part almost every tutorial skips: how “trained on your own content” really works, and the five things that only show up once real people are typing into it.

The four routes, honestly ranked

Route	Effort	Right when
Custom GPT or Claude Project	An afternoon, no code	The users are you and your team, inside ChatGPT or Claude
A hosted chatbot platform	A day or two, no code	You want it on your website, and standard behaviour is fine
Automation platform + retrieval	Days	It must touch your other systems — orders, bookings, CRM
Custom build on the API	Weeks	The behaviour, the data or the interface is genuinely yours

1. A Custom GPT or a Claude Project

Both OpenAI and Anthropic let you make a configured assistant inside their own apps. You give it instructions, upload some files, and it answers using them. No code, no hosting, no API key.

The catch is where it lives: inside ChatGPT or Claude. Your customers are not there, and asking them to sign up to a product they do not use to ask you a question about delivery is not a plan. This route is excellent for internal work — a proposal drafter that knows your tone, an assistant that answers staff questions from your handbook — and useless as a customer-facing widget.

Most people asking how to build a custom chatbot want the customer-facing thing and discover this limit halfway through. Start here anyway: an hour spent configuring one teaches you what your instructions need to say, and that work carries into whichever route you end up taking.

2. A hosted chatbot platform

Point a product at your website, it reads your pages, you paste a snippet, you have a widget. Genuinely good, genuinely fast, and the right answer for a lot of businesses.

What you trade is control and unit economics. You get the behaviour the platform offers, the handoff it offers, the data residency it offers, and a monthly price per seat or per conversation that grows with you rather than with your costs. I have written the comparison honestly, including where the platforms beat a custom build outright, in custom chatbot vs Intercom vs Tidio.

3. An automation platform with retrieval

The middle route, and the one people rarely consider. A workflow tool like n8n sits between a chat widget and the model: it receives the message, looks up the relevant content, calls the API, and — the reason to choose this route — can also check an order status, read a booking calendar, or create a CRM record on the way past.

Pick this when the chatbot needs to do something rather than only explain something. A bot that answers “where is my order” with the actual order is a different product from one that explains your delivery policy.

4. A custom build on the API

Your own code calling OpenAI or Anthropic’s API, your own storage, your own widget. Everything is yours: the interface, the data, the model choice, the cost per conversation, the ability to change any of it later.

Justified when the bot is part of the product rather than a support add-on, when the data cannot leave your infrastructure, or when you have hit a wall the platforms will not move. Not justified because it sounds more serious.

Three questions that choose the route for you

Who types into it — your team, or your customers? Team only: a Custom GPT or Claude Project, today. Customers: it has to live on your site, which rules route one out entirely.
Does it need to look anything up? If answers come only from pages and documents, a platform will do. If it must read an order, a booking or a record, you need route three or four.
What happens when it cannot answer? If “show a contact form” is fine, a platform is fine. If it must reach a specific person, during hours, with the conversation attached, you are building something.

Most projects are answered by question one. A surprising number end at question three, which is the one nobody asks until launch week.

How “trained on your own content” actually works

This phrase does a lot of hiding, and understanding it is what separates a chatbot that works from one that confidently invents things.

It is almost never training. Fine-tuning — actually changing the model — is expensive, slow, and the wrong tool for facts: a fine-tuned model learns a style, not a price list, and it goes stale the day you change something. What virtually every “trained on your data” product does instead is retrieval.

Retrieval is simpler than it sounds. Your content is cut into chunks — a few paragraphs each. Each chunk is converted into a list of numbers that represents its meaning, called an embedding, and stored. When somebody asks a question, the question is converted the same way, the closest few chunks are pulled out, and those chunks are pasted into the prompt along with an instruction like answer using only the text above. The model never learned your business. It is reading the relevant page at the moment it answers, and that is why the answer updates the instant you update the page.

The shortcut that works until it doesn’t: if your whole knowledge base fits comfortably in a prompt — a page of FAQs, opening hours, a price list — skip retrieval entirely and paste it into the system instructions. It is cheaper, faster, and has no failure mode where the right chunk is not found. You will know you have outgrown it when answers start going vague because the important detail got crowded out.

Two practical rules once you do need retrieval. Chunk on meaning, not on length — split at headings so a chunk is a whole idea, because a chunk cut mid-explanation retrieves as half an answer. And return the source: if the bot can say which page an answer came from, you can check it, and so can the customer.

ChatGPT or Claude?

The question everyone asks, and the honest answer is that it matters less than the thing nobody asks about.

Both families are far past the quality bar for answering questions about a business. Broad strokes, and they shift with every release: Claude tends to follow a long list of rules more faithfully and to decline more gracefully when it should not answer, which is worth something when the rules are your liability. GPT has the larger ecosystem and more people who have built with it. Verified pricing and a like-for-like comparison are in GPT vs Claude for business chatbots.

The thing that actually decides quality is your content. A mediocre model reading an accurate, well-organised page beats an excellent model guessing from a thin one, every single time. If your answers are wrong, scattered across three systems, or out of date, no model choice rescues that — and fixing the content usually improves the bot more than any other change you could make.

Build so the model is swappable — one place in the code, your own API key — and the question stops being a commitment.

The five things that only appear in production

Every tutorial ends at “it replied!”. Everything expensive happens after that.

Handoff. A bot that cannot pass a conversation to a person is a wall with a friendly voice. Decide who receives it, during which hours, what happens outside them, and whether the transcript goes with it. This changes the architecture, so decide it before building, not after.
Boundaries. Write down what it must never answer — medical or legal advice, custom pricing, anything about a specific person’s account, promises about dates. Then make refusal a real path that hands off, not a shrug. What a chatbot can and cannot answer goes through where to draw the line.
Hallucination testing. Ask about a product you do not sell and a policy you do not have. A well-built bot says it does not know. A badly built one agrees with you, and that is how a chatbot invents a refund policy you then have to honour.
Cost per conversation. Small, but it should be a number you know rather than a surprise. Keep the keys and the billing in your own account so you can see it.
The improvement loop. Read real transcripts weekly for the first month. Every wrong answer points at a missing or unclear page — and fixing the page fixes the bot and the silent customers who never opened the chat. This is the whole return on the project, and it is the step people skip.

What it costs to run

The model usage is usually the smallest line. At roughly 500 conversations a month, token costs typically land somewhere between a couple of dollars and about twenty, depending on the model and how much context each answer carries. The worked arithmetic is in what an AI chatbot actually costs.

What actually costs money is keeping the content current, and a platform subscription if you took that route. Budget an hour a month for someone to read what it got wrong and fix the source.

When not to build one

Three cases, and I turn down work for all three.

When you do not know what people ask. Pull the last two hundred real messages first. If the top twenty questions are all answerable by a clearer page, write the page — it is cheaper, and it works on everyone who would never open a chat widget. That argument is made in full in how to reduce support tickets with AI.

When the honest answer is “it depends”. If almost every real question needs a human judgement about a specific situation, a bot deflects nothing and annoys people on the way.

When nobody will own it. A chatbot is not a thing you install. Without someone reading transcripts, it drifts out of date and quietly becomes a liability with your name on it.

If you would rather not build it yourself

I build these for businesses: custom AI chatbots trained on your own content, running on your API keys and in your accounts, with the handoff going wherever you actually read messages. From $900 for a focused build and $2,800 for one wired into your systems with human handoff — on the pricing page, with 30 days of support after launch. If you are weighing up hiring someone for it, what to bring to that brief will save you a round trip.

Bring your question log to a free intro call and we will work out which of the four routes you actually need. If the answer is a Custom GPT you can make yourself this afternoon, I will tell you that.

Key takeaways

“Custom chatbot” is four different projects. Who types into it, whether it must look anything up, and what happens when it cannot answer will pick the right one.
“Trained on your data” almost always means retrieval, not training. The model reads the relevant chunk as it answers, which is why the answer updates when the page does.
If your knowledge fits in a prompt, skip retrieval. Add it when answers start going vague.
The content decides quality far more than the model does. Keep the model swappable and stop worrying about the choice.
Handoff, boundaries, hallucination testing, cost visibility and a weekly transcript review are the whole difference between a demo and a system.