The assistant in the corner of this site is called Arkin. We built him the way we would build one for a client, and the first week of real conversations taught us more than the planning did. This is what we did, what went wrong, and what we would tell any business adding an AI assistant to its website.
Start with what it is for
A website assistant has three possible jobs: answer questions about the business, capture leads, or handle support. Doing all three badly is easy. Arkin does the first two. He answers questions from what we have published, and when a visitor wants to talk to us he takes their details and sends them to the same inbox as a contact form enquiry.
He does not quote prices, commit us to timelines, agree to a scope or offer discounts. Most of his instructions are a list of things not to do, and that list matters more than anything telling him what to do.
Keep everything that matters off the browser
The single most common mistake we see in website chatbots is an API key that ships to the visitor's browser. Build tools such as Vite inline certain environment variables straight into the public JavaScript, so a key placed there is published with the site for anyone who opens developer tools.
In Arkin's case the browser sends exactly two things: the visitor's message and a conversation token. The key, the instructions, the knowledge, the model choice and every limit live on our server. A visitor can type anything they like, but they cannot change what Arkin knows or how much he is allowed to spend.
Why there is no vector database
The standard advice is to split your content into chunks, store them in a vector database, and retrieve the few most relevant chunks for each question. That is the right design when you have thousands of documents. Most business websites do not.
Everything we have published - services, case studies, the product, every article and the main pages - comes to roughly 27,000 tokens. That fits in a single request with plenty of room left over, so Arkin reads all of it every time. There is no retrieval step to get wrong.
This matters because retrieval fails quietly. When it picks the wrong chunks, the assistant tells a visitor it does not know about something you have published a whole guide on, and nobody finds out. Reading everything removes that failure entirely, and at this size it costs a fraction of a cent per reply.
The knowledge is rebuilt from the live database every fifteen minutes, so an article published through our writing portal reaches Arkin without anyone changing code. Drafts never do, and every HTML and script tag is stripped before the model sees the content.
A public chat window is a tap connected to your bank account
Every message costs money, and a chat window on a public website can be used by anyone, including a script running all night. Before spending a single token, Arkin checks:
- A monthly spending cap, kept in the database rather than in memory. A cap that resets when the server restarts is not a cap. If spending cannot be counted for any reason, the request is refused.
- An hourly limit per visitor, generous enough for a real conversation and useless for a script.
- Limits on conversation length, message length and reply length, so no single exchange can run away.
We also set a limit in the AI provider's own dashboard, because it is the one ceiling a bug in our code cannot get past.
To tell visitors apart, the rate limiter stores only a salted hash of each address. It needs to know that two requests came from the same place, not who sent them.
Hide it rather than let it fail
An assistant that opens onto an error message is worse than no assistant, especially on the pages meant to win business. So the chat button does not appear until the server confirms Arkin can actually answer: switched on, configured, database ready, budget remaining.
That check also covers the case nobody plans for. If the monthly cap is reached, Arkin quietly disappears for the rest of the month instead of failing in front of a prospect. We tested five server states - not deployed, disabled, cap reached, network failure and ready - and the button appears in exactly one of them.
What the first real conversations taught us
Testing with our own questions caught very little. Real visitors found three problems within days.
He could not count
Asked how many projects we had delivered, Arkin said he did not have an exact number, while every case study was sitting in front of him. Counting items buried in 20,000 tokens is something small models do badly, and their attention is weakest in the middle of a long prompt. The fix was to put a short block of key facts at the very top, with the counts stated outright and generated from the same database queries, so they can never fall out of date.
He did not know who we were
Asked who founded the company, he said he had no information. The founders are named on our About page, but that page is built into the site's code rather than stored in the database, and the knowledge came only from the database. He now also reads the finished HTML of those pages, with the navigation and footer removed so the same menu does not appear seven times.
That exposed a contradiction. The About page says 35+ projects shipped, while 16 are written up as case studies. Both are true, but with both numbers in front of him Arkin would have picked one at random and contradicted himself a question later. The facts block now says which number is which and tells him not to mix them up. If your site contains two numbers that look like they disagree, an assistant will find them before your visitors do.
Walls of text on a phone
We originally told Arkin to avoid bullet points. In a narrow chat window on a phone, his paragraphs did not get read. Now anything with more than two parts becomes a short list, and he answers in the first sentence instead of building up to it.
Formatting brought its own risk. The model writes light markdown, but anything it writes could have been influenced by what a visitor asked it to repeat. So replies are turned into page elements directly and are never treated as HTML, and any link he repeats opens in a new tab and is marked nofollow.
The transcripts are the best research you will get
Every conversation is saved, along with the opening question and the month's spending against the cap. Only full administrators can see them, because these are conversations with real people.
This turned out to be one of the most useful parts of the project. Visitors describe their problems in their own words, which is what keyword tools try to estimate and never quite manage. When a question keeps coming up that no page answers well, that is the next article.
What it costs to run
Our monthly cap is set at about the price of a team lunch, and each reply costs a fraction of a cent. The real cost is the build: getting the knowledge, the limits, the failure handling and lead capture right. A demo chatbot takes an afternoon. One you would trust in front of a prospect takes considerably longer. Our article on what AI automation actually costs in India covers how these builds are usually priced.
If you are adding one to your site
- Decide what it must never say before you decide what it should say.
- Keep the key and the instructions on the server. Check your public JavaScript to make sure.
- If your content fits in a single request, skip retrieval and send all of it.
- Put a spending cap in the database and another in the provider's dashboard.
- Hide the assistant when it cannot answer.
- Read the transcripts every week.
If what you need is closer to an assistant that takes actions - booking, qualifying, updating records - than one that answers questions, read when you need an agent rather than a chatbot. And if you want one built for your business, you can talk to us, or ask Arkin. He will take your details.