AI Chatbot for Your Business Website: A Hard Cost Cap and No Vendor Lock-In

How to add an AI chatbot to your business website without a vendor widget: real running costs, a hard monthly cap and where your data goes.

9 November 202610 min read

Professional at a desk beside a closed laptop looking out over the Melbourne skyline, illustrating an AI chatbot for a business website

Most companies that want an AI chatbot for their business website buy a hosted widget. That means a monthly fee, the vendor's script on every page, visitor conversations stored on the vendor's servers and a copy of your site content sitting in their database. There is another way. For a recent build for an Australian professional services firm, we added an assistant with no chatbot vendor, no database and no vector store, and with a spending limit the code itself cannot exceed.

This article explains how that design works in plain terms, what it costs to run and when it is the wrong choice for your business.

Key Takeaways

An AI chatbot for a business website does not need a vendor widget. A single small server function and a model gateway can do the job.
In our build a six-message conversation cost about USD 0.10, and a month of 200 conversations stayed under USD 25.
If your site content fits in roughly 100,000 tokens, put it all in a cached prompt. Skip embeddings and vector databases entirely.
The strongest protection is a monthly budget cap at the gateway. When the money is spent, requests stop before the model is called.
Conversations still reach an AI provider, so your privacy policy must say so.

What a Hosted Chatbot Widget Really Costs You

The sticker price of a hosted widget is rarely the whole price. You pay a monthly subscription, often tiered by conversation volume. A third-party script loads on every page, which affects speed and gives another company a view of your visitors. Conversations are usually stored overseas. Your product and service copy is copied into the vendor's retrieval system, which you then have to keep in sync with your site.

None of that is wrong for every business. It is simply a bundle you have not priced. Building the assistant into your own site trades convenience for control, and for many firms that is a good trade.

The Design in Plain Terms

A modern marketing site is mostly static pages served from a content network close to the visitor. No server runs when someone reads a page, and no compute is billed. Only the assistant needs code that runs per request, so we add exactly one server function for it. The chat widget sits on the static pages and talks only to that function.

The function does not call the AI provider directly. It calls a model gateway, a separate hosted service that holds the provider key, applies per-visitor limits and enforces a monthly budget. We used Vercel AI Gateway with the firm's own Anthropic key, so the provider bills for tokens at list price and the gateway adds almost nothing. Because the key lives only in the gateway, the website holds no provider secret.

Switching models later is a one-line change, since the gateway speaks to many providers. That is the practical answer to the question every buyer asks about lock-in.

Why a Small Site Does Not Need RAG

Retrieval systems solve a real problem: finding the right passage inside a body of content too large to read in one go. A thirteen-page business website is not that problem. All the copy was already stored in one structured file because the pages are built from it. The assistant reads that file at start-up and turns it into plain text, which becomes its instructions.

We measured the result at about 47,000 characters, or 16,514 tokens. The common shortcut of dividing characters by four predicted about 11,800 tokens, so it undercounted by roughly 40 percent on this kind of writing. Measure from real usage logs and do not trust the arithmetic.

Because the whole site fits in the prompt, there is nothing to retrieve. There are no embeddings to refresh, no vector database to secure and no chunking decisions to debate. When the copy changes, the assistant changes on the next release. Our rule of thumb is simple: under roughly 100,000 tokens of source content, put everything in a cached prompt. Reserve retrieval for content that cannot fit. If your knowledge base is larger, our AI powered platform work includes retrieval systems grounded in your own documents.

Prompt Caching: Why a Conversation Costs About Ten Cents

Sending 16,000 tokens of instructions with every message sounds expensive. Prompt caching changes that. Anthropic's prompt caching lets the provider remember an unchanging block of text, so repeat reads cost about a tenth of the normal input price. The instructions must be identical on every call, with no timestamps, visitor details or request numbers mixed in.

In the first live conversation the 16,514-token block was written to the cache on the first message and read from it on every message after. The numbers from our logs looked like this:

Cost per message - Result: About USD 0.015
Cost per six-message conversation - Result: About USD 0.10
Cost of 200 conversations a month - Result: Under USD 25
Monthly budget cap set - Result: USD 25

These are provider list prices as of September 2026 and they will change, so treat them as a guide to the shape of the cost, not a quote.

Five Layers of Protection Before the Model Is Called

The real fear with any public chat feature is abuse: a script that hammers the endpoint and runs up a bill. The answer is to stack cheap checks in front of the expensive one, so each layer stops traffic at zero cost to you.

Same-origin check - What it stops: Scripts and other sites calling your endpoint
Input shape limits - What it stops: Oversized or malformed messages
Firewall rate limit - What it stops: Bursts from a single address
Per-visitor gateway limit - What it stops: Sustained abuse by one visitor
Monthly budget cap - What it stops: Everything, once the month's money is spent

The last row is the one that lets a small company sleep. When the month's budget is used up, the gateway refuses further requests before the model is touched. Nothing in the application code can spend past it. We also capped each reply length and limited the assistant to a short, bounded number of steps per message, so a confused conversation cannot loop.

Lead Capture Without a Form

A chatbot earns its keep when it turns a question into an enquiry. We gave the assistant one tool: send the visitor's name, email and a one-line summary to the team. The instructions tell it to collect those three things first and call the tool once. The enquiry travels through the same email path as the website contact form, and the transcript leaves the function only as an email to the company inbox. Nothing is stored in a separate database.

Where the Data Goes

This is the part that needs honesty. Messages typed into the assistant go to the AI provider through the gateway, and both may process the text outside Australia. Our build added one paragraph to the privacy policy saying exactly that, and nothing is kept unless a visitor asks to be contacted.

Firms with stricter needs have options. Zero data retention is an organisation-level agreement with the provider, not a switch in the gateway. If the model itself must run in Australia, the same gateway can route to a hosted model in a Sydney region using your own cloud credentials, with one setting changed and no change to the application. Review the OAIC guidance on commercially available AI products before you launch.

When This Design Is the Wrong Choice

Your content is large. Past roughly 100,000 tokens the prompt becomes expensive and retrieval earns its place.
You need live people in the chat. A handoff to a staff member needs real-time messaging and a transcript store. That is a natural next step on the same stack, but it is extra scope.
The assistant must read private business data. Orders, stock and pricing should come through controlled APIs. For firms running IBM i, we can expose that data safely through our IBM i modernisation services, so the assistant sees only the context each question needs.

Related Resources

Common Questions About an AI Chatbot for a Business Website

1. How much does an AI chatbot for a business website cost to run?

It depends on traffic and content size. In our build, a six-message conversation cost about USD 0.10 and 200 conversations a month stayed under USD 25. Hosted widgets usually add a subscription to the usage cost, so compare both.

2. Do I need a vector database for a website chatbot?

Not for a small site. If all your content fits in roughly 100,000 tokens, place it in a cached prompt and skip embeddings and vector storage. Retrieval is for content too large to fit.

3. Can I set a spending limit on an AI chatbot?

Yes. A model gateway can enforce a monthly budget and refuse requests once it is reached, before the model is called. Per-visitor limits and firewall rules add further protection.

4. Is it safe to put customer conversations through an AI provider?

It can be, with disclosure and care. Tell visitors in your privacy policy that messages go to an AI provider, avoid collecting sensitive details in chat, and consider zero data retention or an Australian model region if your sector requires it.

5. Can the chatbot capture leads?

Yes. Give it a single tool that sends the visitor's name, email and enquiry summary to your team by email. It avoids a separate form and needs no database.

A Spending Cap Turns an AI Chatbot Into a Safe Experiment

The point of this design is not the cleverness of the code. It is that the risk is capped before launch: a fixed monthly ceiling, a short list of protections and a clear statement to visitors about where their words go. With those in place, a business can trial an assistant for the price of a few coffees and keep full ownership of the result.

If you want an assistant on your site, or one that can answer from your own systems, send 9Byte a brief and we will scope it against a budget you set.