Skip to content

Work

What we have built so far

One entry, and it is our own. The studio is new, so rather than fill this page with logos we have no right to show, here is the reference build of the system we sell — the same architecture a client engagement produces.

Demo build — not a client project

AI Front Desk reference build

The working reference implementation of our WhatsApp front desk, built against a synthetic clinic so the architecture could be tested end to end before it was ever sold.

Sector
Healthcare — internal reference build
Duration
Built over three weeks; the productised version deploys in ten days
Stack
WhatsApp Business APIPythonFastAPIPostgreSQLpgvectorNext.jsTypeScript

Why we built it

Selling a ten-day delivery promise is only honest if the system already exists and the ten days are configuration rather than invention. So we built the whole thing first — against a fictional multi-doctor clinic with a document set, a calendar and a question bank we wrote ourselves — and timed how long a fresh deployment actually takes.

How it is put together

Patient messages arrive over the WhatsApp Business API into a FastAPI service. Clinic documents are chunked and embedded into PostgreSQL with pgvector, and every factual answer is grounded in a retrieved passage. Booking is deliberately not left to the model: the assistant calls a scheduling service with ordinary, unit-tested rules for slot length, buffers and doctor leave. Anything clinical, angry or ambiguous is classified and handed to a human queue with the conversation attached.

How we know it works

A graded evaluation set of realistic patient messages — including transliterated Tamil, half-typed numbers, and questions the documents genuinely do not answer — runs on every change. The interesting cases are the refusals: a correct "I will pass this to the front desk" scores as a pass, and a confident wrong answer scores as a failure regardless of how fluent it is.

What it taught us

Most of the difficulty was never the model. It was WhatsApp template approval latency, the fact that people send appointment times as voice-note-style fragments, and deciding exactly where the assistant should stop and a human should start. The ten-day plan is shaped around those three things.

What came out of it

  • Full deployment path rehearsed end to end, which is what the ten-day timeline is based on
  • Evaluation harness runs on every change and ships to clients as part of the handover
  • Escalation and refusal behaviour tested before any real patient was ever involved

Want to be the first case study on this page?

Early clients get our full attention and a lower fixed price, in exchange for permission to write the engagement up once it is live. Any numbers published here will be yours, approved by you, and real.

First real case study on this page could be yours.

Early clients get full attention and a lower fixed price, in exchange for permission to write it up once it is live.