We Built an AI Assistant for Our Website — Here's What We Learned

Last month, a visitor asked our AI assistant a question about headless CMS pricing at 11:40 pm on a Saturday. It gave a clear, accurate answer, linked to two of our articles, and suggested the Solution Finder quiz. We were asleep. That one interaction convinced us the build was worth the three days it took.

We sell AI-ready web solutions. If our own site didn't demonstrate that, we'd be hypocrites. So we built a custom AI chatbot using the Anthropic Claude API, embedded it as a chat widget on breemedia.com, and learned a lot about what works, what doesn't, and what costs less than you'd expect.

This is the honest breakdown.

Choosing the Model (and Why Haiku Won)

Anthropic offers several Claude models. The two that mattered for us were Sonnet and Haiku. Sonnet is smarter. Haiku is faster and cheaper. For a website assistant answering questions about our services, Haiku was the obvious pick.

The reasoning was simple. Our assistant doesn't need to write essays or debug code. It needs to answer "What does a website cost?" quickly and accurately, then point visitors in the right direction. Claude Haiku handles that at roughly $1 per million input tokens and $5 per million output tokens. A typical conversation with our assistant costs a fraction of a cent.

We cap responses at 1,024 tokens. That's enough for a solid two-to-four sentence answer without runaway costs. We also limit conversations to 20 turns, which sounds restrictive until you realize that most visitor conversations are three to five messages. Nobody's having a 20-turn chat with a business website.

Our monthly API bill? Between $5 and $20 depending on traffic. That's less than a single stock photo on most subscription services.

The System Prompt Is the Whole Product

Here's something that surprised us: the system prompt took longer to write than the code. And that's not an exaggeration.

The chat widget itself is vanilla JavaScript. The API proxy is a straightforward Express endpoint. The streaming connection uses Server-Sent Events. All of that took maybe four hours. The system prompt took two full days of writing, testing, and rewriting.

The system prompt is your chatbot's entire personality, knowledge base, and set of guardrails packed into a single block of text. Get it wrong and your assistant gives vague, unhelpful answers. Get it very wrong and it starts promising timelines you can't deliver.

We stuffed our system prompt with everything: services, pricing ranges (always with "depending on scope"), process details, article summaries, what we do, what we don't do, and explicit instructions about tone. "Confident, warm, direct — never salesy or pushy." That line is in there verbatim.

A few things we learned about prompt engineering for business chatbots:

• Be specific about what the assistant should never do. Ours won't give fixed quotes, name competitors, or promise delivery dates. Those boundaries prevent most of the "AI said something embarrassing" scenarios.
• Include your actual service descriptions, not marketing copy. The assistant answers better when it has concrete details like "WordPress, custom CMS, headless CMS with Strapi or Sanity" instead of "we create powerful digital experiences."
• Tell it how to handle questions outside your scope. We added a line: "We don't do native mobile apps, social media management, or paid ads. Say: That's not our focus, but we're happy to recommend someone." Without that instruction, the assistant would try to be helpful and start making things up.
• Update the prompt when you publish new content. Every time we add an article, that article's title, URL, and a short summary go into the system prompt so the assistant can recommend it naturally.

That last point matters more than it sounds. We wrote about how to get recommended by AI search engines and one of the core ideas is that AI systems need structured, clear information about your business to represent you accurately. Your own chatbot is no different.

The Technical Stack (Deliberately Simple)

We didn't use LangChain. We didn't use a vector database. We didn't build a retrieval-augmented generation pipeline.

We used Express, the Anthropic SDK, and about 60 lines of server-side JavaScript.

The architecture looks like this: the chat widget on the frontend sends a POST request to our /api/chat endpoint. That endpoint injects the system prompt, forwards the conversation to Anthropic's API, and streams the response back via Server-Sent Events. The text appears word by word in the browser, which feels fast even when the full response takes a second or two to generate.

Conversation history stays in the browser's sessionStorage. Not localStorage, not a database, not a cookie. When you close the tab, the conversation disappears. That was a deliberate privacy decision. We don't need to store what visitors ask us, and frankly, we don't want the liability of holding that data. The Anthropic API is stateless anyway — we send the full conversation history with each request, and they don't retain it after processing.

For security, the API key never touches the browser. It lives in an environment variable on the server. The proxy endpoint has rate limiting (20 requests per minute per IP), input length caps (1,000 characters per message), and the system prompt includes explicit instructions to refuse prompt injection attempts. We wrote about security headers and API protection in a separate article, and we followed our own advice here.

One thing that caught us off guard: the system prompt counts as input tokens on every single request. Ours is around 1,500 words. That means every conversation turn costs slightly more than you'd expect because the full system prompt is re-sent each time. At Haiku's pricing this is trivial, but it's the kind of thing that would matter on a more expensive model.

What Didn't Work (and What We Changed)

The first version of our assistant was too eager to help.

We'd ask "Do you build mobile apps?" and instead of saying no, it would say something like "While we don't build native mobile apps, we can create progressive web applications that function similarly on mobile devices." Technically accurate. Practically misleading. We don't sell PWAs as a service, and that answer would set an expectation we'd have to walk back.

The fix was blunt. We added explicit "don't do" instructions and told the assistant to redirect gracefully. "That's not our focus, but we're happy to recommend someone" is the exact phrasing, and it works.

The second problem was response length. Early versions gave long, thorough answers that would be great in a support article but terrible in a chat window. Nobody wants to read four paragraphs from a chat widget at 320 pixels wide. We added "Keep responses concise (2-4 sentences unless asked for detail)" to the system prompt and the difference was immediate.

The third issue was subtler. The assistant would sometimes describe our process in a way that was slightly different from how we actually describe it on the site. The discovery phase became "initial consultation." The strategy phase became "planning." Small inconsistencies that could confuse someone who'd already read our How We Work section. We fixed this by copying the exact language from our site into the prompt. Not a summary of it. The actual wording.

The starter prompts were another lesson. We launched with four pill-shaped buttons above the chat input — "What services do you offer?", "How much does a website cost?", "How does your process work?", and "I need an accessibility audit." These do two things. They show visitors what the assistant can handle, and they give us four well-tested conversation openers that we know produce good responses. About 60% of conversations start with one of those pills.

Was It Worth Building?

Yes. But not for the reason we expected.

The direct lead generation is modest. We're a small consultancy. We don't get thousands of visitors a day. The assistant handles maybe 30-50 conversations a month, and most of those are exploratory questions, not hot leads ready to sign a contract.

The indirect value is where it pays off. The chatbot connects to our Solution Finder quiz. When someone asks a question that suggests they're evaluating whether to hire us, the assistant suggests the quiz as a next step. That handoff works well because the quiz is already a core part of our conversion strategy. The assistant acts as a guide to it, not a replacement for it.

There's also a credibility factor. We talk about AI-ready websites, AI search, how businesses should think about AI integration. Having an actual AI assistant on our own site that clearly knows our business backs up every claim we make. It's proof of work.

And the honest truth about cost: this entire project — the widget, the API proxy, the streaming, the system prompt, the starter prompts, the security setup — costs us less per month than a single cup of coffee per day. The engineering time was the real investment, and even that was under a week.

If you're a business thinking about adding an AI assistant to your site, here's our take: don't use a generic chatbot platform that knows nothing about you. The value is in the system prompt, the specific knowledge about your services and process that turns a language model into something that actually represents your business. A generic "How can I help you today?" widget with no business knowledge is worse than no chatbot at all, because it wastes your visitors' time and makes your site feel cheap.

Build it custom. Keep it simple. Write a system prompt that would make sense if you read it out loud to a new employee on their first day. That's the whole trick.

Sources

• Anthropic Claude API Documentation — Models Overview
• Anthropic — Building Effective Agents
• Claude API Pricing
• MDN Web Docs — Using Server-Sent Events
• Anthropic Academy — Build with Claude
• IBM — The 2026 Guide to Prompt Engineering
• Lakera — Prompt Engineering Guide 2026