We added an AI assistant to our site in a day. Here's the whole build.

The chat bubble in the corner of this site is an AI assistant. We built and shipped it in a single day: seven commits, one API route, one knowledge file, no framework. This is the build log, written from the actual git history, including the parts we got wrong.

We're publishing it because we sell AI automation, and "show me yours" is a fair test of anyone selling automation. So: here's ours.

Why bother?

Visitors ask the same fifteen questions: what does a site cost, how long does it take, do you work with companies outside Glasgow. Our email response time is around four hours, which is good for an agency and terrible compared to instant. An assistant that answers the common questions immediately, around the clock, and captures a name and email when someone's interested, pays for itself with a single enquiry.

The architecture, honestly

There's a fashionable way to build this (vector database, RAG pipeline, embeddings, a framework with a mascot) and there's the way that fits a ten-page agency site. We picked the second:

• One knowledge file. Everything the assistant knows lives in a single hand-written file compiled from our live pages: services, real prices, case studies, contact routes. It's about 70 lines. The rule in the file's header: when a page's facts change, update this file in the same commit. At this size, RAG would be engineering theatre. The whole "knowledge base" fits in the prompt with room to spare.
• One API route. A visitor message goes to our server, which calls OpenAI's gpt-4o-mini and returns the answer. Replies are capped at 400 tokens because this is a chat widget, not an essay.
• Instant answers for the common stuff. The most-asked questions never hit the API at all. They're matched client-side and answered from pre-built responses in milliseconds, with follow-up question chips so the conversation keeps moving. Faster for the visitor, free for us.
• Lead capture built in. The widget asks for a name and email before the chat starts, and the transcript is emailed to us when the conversation closes. The assistant's actual job is qualifying enquiries; answering questions is how it earns the right to do that job.

The layer most builds skip: abuse

Put a free text box on the public internet and two things arrive within days: people trying to use your widget as free ChatGPT, and people trying to make it ignore its instructions. Our defence is a two-stage design:

• Stage one is a gatekeeper. A separate, tiny model call that sees only the last few messages, has zero site knowledge in its context, and answers with a single word: on topic or off topic. Homework requests, coding help, "ignore your instructions and..." attempts get a one-line refusal and the answering model is never called. There's nothing to jailbreak because the model with the knowledge never sees the message.
• Stage two answers, from a system prompt that treats every visitor message as untrusted input and refuses to discuss its own instructions.
• Boring limits do the rest. Thirty messages per ten minutes per visitor, a thousand characters per message, sixteen messages of history. And we send OpenAI a hashed pseudonymous visitor id rather than raw IPs, so abuse patterns are detectable without handing over more data than needed.

If it all fails anyway, the widget degrades to the only fallback that matters: our email address and a promise to reply within four hours.

What it costs to run

Near enough nothing. A typical answered message involves roughly 1,500 to 2,000 prompt tokens and up to 400 output tokens on gpt-4o-mini, which works out to a small fraction of a penny per answer. The gatekeeper call is capped at five output tokens, so it's a rounding error on a rounding error. The pre-built instant answers cost literally zero. At realistic traffic for a site like ours, monthly model spend is pocket change; the meaningful cost was the build day.

What we got wrong

• Version one had no gatekeeper. We shipped the grounded assistant first and added the abuse layer in a later commit the same day. The right order is the reverse: assume bad traffic from the first deploy, because any public chat box is an invitation.
• We under-planned for latency on the obvious questions. Watching a spinner for a question we've answered a thousand times felt broken. Pre-built instant answers should have been in the first commit, not the third.
• Desktop-first was a mistake. The widget needed a dedicated mobile pass (full-height sheet, keyboard handling, body scroll locking) because most of the traffic that actually uses a chat widget is on a phone.

One detail we got right and will defend: the system prompt bans em dashes, tells the model to keep to British English and pounds sterling, and instructs it to say "this might not be worth paying for" when that's the honest answer. Grounding isn't just facts. Voice is part of the spec.

Should your business build one?

This pattern fits when three things are true: visitors ask repeating questions, the honest answers live on your site already, and an enquiry is worth real money to you. That's most service businesses. It doesn't fit if your answers change hourly, if you can't commit to keeping the knowledge file honest, or if you'd be gluing a chat box on because everyone else has one.

We build this exact setup for clients, gatekeeper and all, alongside bigger workflow automation on Make.com. Fixed price, scoped upfront: AI automation services. Or just open the chat bubble in the corner and interrogate the thing itself. It knows our prices better than we do.