Namiru.ai is an AI front desk for small venues and service businesses. You paste your website URL, and within about 30 seconds an agent answers customers, books appointments and captures leads, 24/7. The hard problem behind that one sentence is not chat. It is letting a model speak for a stranger's business without inventing a single fact about it.
This case study is about how we solved that, and what it means for clients who want an AI product that survives contact with real customers.
The brief we gave ourselves
Namiru.ai is our own product, so we wrote the brief ourselves, and it got sharper over time.
The target is a small service venue. A handful of services, lots of evening questions, and one owner who cannot be everywhere. At 9 pm that owner is not answering the website chat. The visitor who wanted to book leaves.
So the tool had to:
- install in one line, on whatever the site already runs on,
- answer only from what the business actually says,
- book or hand off honestly, never pretend,
- cost less per month than a single lost booking,
- be legal to run in the EU without a compliance project.
What we built
The flow has three steps. Paste a URL, and the system crawls the site and builds the agent. Add one snippet to the site: WordPress, Shopify, Wix, or the npm packages for React, Vue and Angular, plus a dedicated WordPress plugin. The agent then answers, books into a calendar, captures leads and reports back.
Around that flow sits a product with three jobs.
Answer. Customer support from the crawled site plus uploaded files, a knowledge base with optional source citations in chat, and a product catalog from an XML or JSON feed. Replies come in the visitor's language, detected automatically from their message, and the widget and booking interface are localized into 19 languages.
Convert. Bookings with services, prices and durations, weekly availability, booking lengths from 15 minutes to full days, per-visitor limits, buffers and blocked dates. Bookings live in Namiru, with optional two-way Google Calendar sync that blocks busy time to prevent double bookings. Lead capture and qualification with email export. When the monthly credits run out, the widget falls back to collecting email addresses instead of disappearing.
Improve. Conversation analysis groups topics, detects pain points with a severity, and sends weekly insights. Trouble alerts email the owner a conversation when frustration is detected. Live handoff works by email and in the app today; Telegram, Slack, Discord, WhatsApp and Messenger are in early access.
Architecture
visitor
|
widget (UMD script, React / Vue / Angular packages, WordPress plugin)
| WebSocket with session resume
chat service ----> agent runtime: prompt assembly, tools, knowledge
| | | |
transcripts Qdrant bookings + lead capture
(durable) vectors Google Calendar
|
owner: alerts, handoff, weekly insightsThe system is split into two backends. backend-api owns the product: crawling, persistence and billing. backend-ai owns the agent runtime: prompt assembly, tools and the WebSocket chat server. Data sits in Postgres with TypeORM migrations, Redis caches agent configuration, and Qdrant holds the vectors. Stripe handles subscriptions and one-time top-ups, and Google OAuth powers the calendar sync.
The chat transport is a WebSocket with a session resume protocol. Transcripts are durable, and rich content such as a booking form is replayed on resume, so a full page reload does not lose the conversation.
The crawl pipeline serves three callers (signed-in users, public demos and outreach) through one shared service on a self-hosted Firecrawl instance. It discovers the sitemap, scores URLs, promotes critical pages such as pricing and booking, extracts each page into structured knowledge, and stops at a bounded page budget.
Every change goes through unit tests per service and Playwright end-to-end tests across all three services, then a staged deploy to a test stack in a fixed order: API first, then the AI service, then the frontend and widget. The repository passed 1,100 commits on the way from the first commit on 23 October 2025 to version 1.0.0 on 13 August 2026.
Three problems worth solving properly
1. Grounding: answering for a stranger without inventing facts
A model that reads a website will happily fill gaps with plausible fiction. For a business, a confident wrong answer about prices or opening hours is worse than no answer.
So the site profile extraction is schema-driven, and every assertion carries evidence: the source URL and a verbatim excerpt from that page. The model works against an index of URLs that were actually observed during the crawl, so it cannot emit a link that never existed. If the evidence does not support a claim, the claim does not make it into the agent.
2. Never fake availability
The most dangerous question a front desk gets is "do you have a slot on Friday?". An answer that is not connected to the real booking system is worse than silence.
The agent follows a fail-closed order. If the owner connected a calendar, it uses that. If not, but the site has its own booking page, it hands the visitor that link. Otherwise it says honestly that it does not know. Deterministic filters also strip live availability and computed totals from crawled booking pages, because a snapshot of last Tuesday's free slots is a lie by Friday.
3. Cost per conversation
The Starter plan includes 2,000 conversations for €29 and Pro includes 5,000 for €59, which works out to roughly €0.01 to €0.015 per included conversation, or about €0.02 with the framing used on the pricing page. Enterprise support tools commonly charge around €1 per resolved chat.
That price is only possible with the cost side engineered from day one: bounded crawls instead of crawling everything, task-specific model lanes so cheap work runs on cheap models, per-call cost accounting surfaced in an internal AI spending view, and the platform running on our own hardware. To be precise, those are our prices, not our costs; the point is that the architecture leaves room between the two.
Running it in the EU
Compliance was a design input, not a checkbox at the end.
- The platform is hosted in Germany.
- Every chat discloses that it is an AI, as the EU AI Act requires.
- Nothing is stored before the visitor opens the chat. This constrains the widget architecture directly: the script can load and render the launcher, but it may not create a visitor record, a session or a transcript until the visitor acts.
- A data processing agreement is included, with deletion on request.
What changed because real people used it
The lost booking that rewrote the crawler
Two prospects opened their auto-generated demo agent and asked it booking questions. The agent had nothing useful to say: it was not connected to their booking system, and one site's own reservation page was invisible to the crawler.
That was the end of the text scraper. The crawler was rebuilt into the schema-driven extractor described above, one that identifies what a business sells, whether it already takes bookings, and where. The fail-closed booking order came straight out of those two conversations.
Finding the customer
Namiru started as "an AI chat widget for businesses", which meant no business in particular. Watching how visitors to an experience venue actually used it narrowed the product to small service venues. Everything downstream changed, including the homepage category, from "customer support" to "AI front desk".
The dashboard nobody would trust
The early dashboard showed "hours saved" and "cost savings" computed from a few dozen conversations. Numbers an owner cannot check destroy trust in the numbers they can. The dashboard was rebuilt around one question at the top of the screen: what needs you today.
What Crowie takes from this into client work
We run Namiru.ai as a production SaaS. We wrote it, we deploy it and we answer for it when something breaks. That is what we bring to client projects:
- a crawl and extraction pipeline that grounds answers in evidence, from our custom AI development practice,
- the platform engineering around it, from web application development,
- EU deployment on dedicated hardware we operate,
- and the habit of measuring what an AI feature costs per call before it ships.
We also wrote down the most common mistakes we see in AI customer support deployments, and our sister product VibeiDE shows the same approach applied to developer tooling.
If you are planning an AI product or an agent wired into your own systems, book a free roadmap call. If you run a small venue and want the front desk itself, try Namiru.ai on the free plan.