Mo

Most of the questions that reach a small studio are the same few: can you do what I need, roughly what does it cost, and how does this start. They arrive at every hour, they need a real answer rather than a form receipt, and a chatbot that guesses at prices or invents past work does more damage than no chatbot at all.

Build an assistant that is allowed to be genuinely useful and not allowed to make anything up. Mo answers from the site's own content, so its answers match the packages and pricing a visitor can read on the same page. When the conversation reaches the point of real intent, it gathers what a quote needs and passes the enquiry on rather than pretending to close it.

Claude through the Anthropic API, called from a Netlify serverless function written in TypeScript, in front of a static Astro site. The browser talks only to that function, so the API key stays on the server and never ships to the client. The function checks the request before it calls the model: anything that fails those checks is rejected at the edge instead of being paid for. The assistant is grounded in the site's real content, and the prompt is built so that instructions typed into the chat cannot override it. If the function cannot be reached, the widget degrades to a human route rather than failing silently.

• Answers only from the site's own content, so it cannot invent a price or claim work that was never done
• Qualifies the enquiry, then hands it to a person with the detail already gathered
• The API key stays server-side in a Netlify function and never reaches the browser
• Resistant to prompt injection, so instructions typed by a visitor cannot rewrite its rules
• Cost controls reject a request before it reaches the model and gets billed
• Falls back to a human route when the assistant cannot be reached
• POPIA-mindful: it says what the details are for before it asks for them

Deciding what Mo is not allowed to do, before deciding what it could do. An assistant on a studio site is a sales surface, and the tempting version answers everything with confidence. That version eventually quotes a price that does not exist or claims a project that was never built, and the client finds out in front of a customer. So the grounding came first: Mo answers from the site's real content, and when it does not know, it says so and offers a person. The same instinct runs through the rest of it. The key lives server-side because a key in the browser is somebody else's bill. Requests are rejected before the model call because a cost control that runs after billing is not a cost control. Visitors are told what their details are for before they are asked for them, because that is what POPIA expects and it is the decent way to ask.

Mo is live on mowebsites.co.za and open to anyone who visits. It answers questions about the packages, works out what a visitor needs, and lands qualified enquiries in the same pipeline the site's own form feeds. It is early, and it is a real shipped system rather than a demo.