Enamel

The AI operating system for a small dental clinic — records, scheduling, billing, lab and stock. The AI runs on the clinic's own computer, fully offline. One-time licence, in daily clinical use.

Comment

Inspiration

I am a practising dentist. Enamel started because I was losing to my own paperwork.

My clinic has over 6,700 patients and eleven years of history. It ran on cloud practice-management software, which meant two things I had quietly accepted: my patients' records lived on somebody else's server, and when the internet dropped — which in an Indian town it does — my clinic stopped being able to look up a patient.

Meanwhile every AI tool I was offered wanted me to upload X-rays and clinical notes to a server in another country. For a dentist, that isn't a preference. It's a conflict between wanting the tool and being responsible for the record.

So I asked a narrower question: what if the records and the AI both stayed on the computer already sitting in the surgery?

What it does

Enamel is the operating system for a small dental clinic. Not one feature — the whole operation:

  • Patient records, FDI tooth charting, clinical notes, prescriptions
  • Appointments, recalls, and a separate "call before visit" list
  • Treatment plans and estimates, payments, collections, consent with an on-screen signature
  • Dental lab case tracking, and clinical stock with reorder levels
  • Revenue sharing for visiting consultants, and an owner's dashboard

It is sold as a one-time licence, ₹6,999 per clinic. No subscription. Pull out the internet cable and it keeps working.

How the AI is actually wired

The AI is not a chat box bolted onto a CRUD app. It is how the operation runs, and it is deliberately split across two places.

On the clinic's own computer, through Ollama:

  • Gemma 3 drafts the clinical note while the dentist speaks. Dictation runs through a vendored whisper.cpp build, so speech never leaves the machine — which matters when a dentist dictates in Marathi.
  • MedGemma 1.5 reads intraoral X-rays into a structured clinical checklist, and learns from that clinic's own confirmed past readings. It is an assistant the dentist confirms. It is never a diagnosis.

In the cloud, via the Gemini API — and only for things that contain no patient:

  • The demo host that answers prospective customers' questions on the public demo, unsupervised
  • Marketing poster copy and artwork
  • Patient-education video scripts, generated through a multi-agent graph with a reflection loop and a deterministic safety check that rejects PII and guarantee claims before anything reaches a patient

Published education videos are stored in Google Cloud Storage.

The line is absolute: the cloud only ever sees a procedure name like "root canal". It never sees a patient.

How we built it

I am one dentist, not a team. The build loop is:

  1. I write a build brief describing the problem and the decisions already taken
  2. An AI coding agent implements it
  3. A separate verification pass reviews the result, adversarially, before anything ships

Step 3 is the one that matters, and I learned it the hard way. AI writes code far faster than any human can check it, so the scarce resource is not implementation — it's verification. Making the reviewer a different process from the builder is the only thing that consistently catches what the builder cannot see about itself.

Challenges we ran into

A green test suite cannot see that the app won't boot. One slice shipped with 425 passing tests and a white screen — an edit had replaced an import line instead of adding one. The build succeeded, every test passed, and the application was dead. Now nothing ships without being loaded in a real browser, and I make a new test fail once before I trust it.

Indian names have no single Latin spelling. Searching "Alka" on my own database returned 96 patients, of whom only 28 were named Alka — the rest were Marathi surnames like Tandalkar and Nimbalkar that merely contain the letters. The patient I wanted sat nineteenth and was invisible. Substring matching is almost never what an Indian-name search means, so results are now ranked by how the name actually starts.

The same screen was also downloading 1.97 MB per keystroke to display eight rows. The database was never the problem; the payload was.

The image model wrote the wrong word in Hindi. Asked for a poster headline about pain, it painted दाद — ringworm — instead of दर्द. Twice, identically. So no word a patient reads is ever painted by an image model now. Artwork text stays English; the caption underneath is generated as ordinary text and comes out clean in thirteen languages. We say this out loud in our marketing rather than hiding it.

Licences are machine-bound, which creates a chicken-and-egg problem. A licence cannot exist until the software is running on that exact computer, so the first two clinics were asked to find a hardware fingerprint and send it back. Neither did. Both concluded the software was broken. The fix was to put the code in the banner they were already staring at, next to a one-tap button — and a QR code for the normal case where an Enamel machine has no internet at all.

Accomplishments that we're proud of

My own clinic has run on Enamel daily since 4 August 2026 — over 6,700 patients, more than 12,500 clinical records and 8,800 payments migrated, with new visits recorded in it every day since. Those figures rise weekly, because it is a working clinic rather than a demonstration.

Seven clinics now hold a copy. I want to be precise rather than flattering about that number: one is my brother, one is a long-running unpaid pilot, one is a consultant who visits my own practice, and one is a trial. Three are arms-length. Every copy is recorded in a distribution ledger against the build it received, so if a bad build ever goes out I can answer the only question that matters — which clinics have it.

What we learned

That the interesting constraint was never "can the model do it". It was "can a dentist trust it at four in the afternoon with a patient in the chair" — and almost everything above is what that question turned out to demand.

What's next for Enamel

Every item below was asked for by a named dentist. None of it is a wish list.

A shared view across two clinics. Two customers have now described the same problem independently. One runs two practices and wants a single multi-clinic view. The other closed her second clinic last year because patients kept turning up at whichever one suited them and it became unmanageable — a scheduling problem that shut a business. Today, one install is one clinic. That is the next thing I build.

Periodontal charting and implant tracking, voice first. Enamel has neither, and I said so in the first minute of a demo to a periodontist rather than discovering it later. He is now trialling it, and has agreed to specify what a perio chart he would actually use looks like. The hard part is not the data model — it is that charting six points per tooth by keyboard is what makes dentists abandon perio charts. It has to be dictated. The vendored whisper build already runs on the clinic PC, so the ingredient exists; the discipline is that voice may only write where the write is bounded and visible on screen — never a prescription, never a tooth status, never a payment.

RadIQ beyond intraoral. The on-device X-ray reading currently handles intraoral radiographs. Panoramic OPG is next, then 3D CBCT. Both are stated as roadmap in the product itself, never as something it already does.

Removing the last shared secret. Cloud features currently need each clinic to supply its own Google AI key. That is honest but clumsy for a dentist. A thin proxy would let a clinic buy credits without ever handling a key — the design is decided, the work is deliberately after this submission.

More arms-length clinics. Three of the seven copies are genuinely arms-length today. That number, not the seven, is the one I am trying to move — and it is the only one that tells me whether this is a business or a hobby.

The constraint that shapes all of it: anything added has to work on a clinic computer with the internet unplugged. That rules out a lot of easy answers, and it is the whole reason the product is worth building.

Built With

Share this project:

Updates