A clinic: 52 pages, an assistant and a smile simulator

How it worked before

The site had to carry three cities, two languages and a stream of questions the clinic has nobody to answer daily.

What made it hard

The clinic has no IT department, so the site has to hold itself up: not fall over when something breaks, not bankrupt the owner in tokens, and not store anything about patients it doesn't need. A photo of a face is its own problem — sensitive data, to be handled as such.

Engineering decisions

1. 01

   The assistant answers from the pages, not from the model's memory

   Its own knowledge base per language, with the selected context cached. It will not invent a service the clinic doesn't offer.

2. 02

   No key, no outage

   The service returns a clear error, the widget quietly goes offline, and the page keeps working. An assistant that falls over must not take the clinic's site with it.

3. 03

   Spend is held down in four places

   A short question, a short history, an economical model and a cached context — plus a cheap filter for off-topic requests before the model is called at all: "write me a poem" costs nothing.

4. 04

   A photo of a face is stored nowhere

   It arrives in memory, goes to the provider, the result returns to the patient — no disk, no logs. On top of that a cap on generations per address, because generation is paid.

Where it stands

Live. The image provider is swapped with an environment variable — the editing model is set from outside, so changing it does not touch code.