Tooth PrintAI-search-ready website and CMS for a dental clinic
- Custom Software Development
- UI/UX Design
- AI Search Optimisation
- Local SEO
- Healthcare
- New Delhi, India
- Live site
01 — The Challenge
A presence the clinic owns, not a row in someone's table.
The founders wanted the opposite of a listing: a presence they own, that reflects how they actually practise — calm, personal, credible — and that meets patients where local intent really happens, on a phone, in a moment of need.
Three ordinary assumptions about clinic websites had to go first.
The first is that the clinic is the unit. Patients do not book a brand; they book a person they have already started to trust. A site organised around services buries the only thing that earns that trust, which is why aggregators — which at least show you a face and a name — keep winning the click.
The second is that search means Google. Patients increasingly put the question to an AI assistant instead, and those systems answer from whatever structured, authoritative source they can read. Most local businesses expose none, so they are simply absent from the answer.
The third is that a calm site is a matter of taste. Dental visitors are frequently nervous, in pain, or booking for an elderly parent. Cluttered templates, stock smiles, countdowns and pop-ups push away exactly the visitor the clinic needs, so restraint here is the conversion mechanism rather than a preference.
02 — Founder-Led Structure
A founder-led information architecture, built on a clinic-owned CMS.
A clinic's strongest asset is its doctors. We built the site around a dedicated profile page for each dentist — credentials, specialisations, treatment philosophy — with services and patient case studies linking back to the person who delivers them.
Seven doctors, seven profiles, each one a landing page in its own right. That is seven entry points into the clinic instead of one, each answering the question a patient actually typed.
Each card carries the specialisation, the years in practice and the treatments that dentist actually covers — a root canal, implants, clear aligners, a child's first visit — so someone arriving with a specific problem picks the right person before they ever pick up the phone.
03 — The Design System
One blue family, because the category already owns the colour.
Oral care spent decades teaching people that clinical blue means clean and competent. We took that rather than fought it: the whole site is one blue family — a deep navy carrying the structural weight, a teeth-bright accent carrying the calls to action, and a navy-tinted neutral doing everything else.
Everything else is subtraction. WCAG 2.1 AA contrast, reduced-motion support, and type sized for an older patient reading on a phone in bad light. No pop-ups, no countdowns, and real photography of the founders instead of stock smiles.
The question on every decision was whether it lowers the anxiety someone already carries into a dental visit, or raises it.
04 — Conversion Paths
Conversion paths built for a phone: call, WhatsApp, directions.
We built for the phone, because local healthcare converts on one. We keep tap-to-call, WhatsApp and get-directions within reach on every page, so the distance between "found you" and "talking to you" is one tap. No mandatory forms, no gated content.
The doctor profiles carry the same paths, so a patient who arrives on a specific dentist can book against that dentist without navigating back to a generic contact page.
05 — Discoverability and Ownership
An AI search stack: structured data, local SEO, llms.txt.
We went past classical local SEO — consistent name-address-phone data, sitemap and robots configuration — and published the clinic as a machine-readable entity. The structured data is a schema.org Dentist node rather than a generic business listing, carrying opening hours, postal address, geo coordinates, the areas served, ratings and reviews, with FAQ markup on the pages that answer questions.
Structured data only helps a reader that runs the page. The llms.txt endpoint is the one that does not need to: it is rendered by the server at a plain URL, so a crawler or an assistant that never executes JavaScript still gets the clinic, its doctors and its services in full.
It is generated from the CMS rather than written once and forgotten, rendering the current doctors and posts on request, so a profile edited this morning is what an assistant reads this afternoon. When a patient asks an AI assistant for a dentist in Lajpat Nagar, Tooth Print is legible to the system doing the answering.
A Filament-powered admin panel lets the clinic update services, doctor profiles and patient case studies without a developer — with PHPStan at level 7 and an automated test suite guarding the platform underneath, so a routine content edit cannot quietly break the site.
06 — Snapshot
The Tooth Print build: stack, scope, shipping model.
| Client | Tooth Print Dental Clinic |
| Location | Lajpat Nagar, New Delhi |
| Founders | Dr. Kirti Verma and Dr. Rhitam Debnath |
| Scope | Laravel CMS with a doctor-led information architecture, local SEO and an AI-discoverability stack |
| Doctor profiles | 7, each a landing page with its own conversion path |
| Frontend | Inertia.js with Vue, Tailwind CSS, Vite |
| Backend | Laravel with a Filament admin panel |
| Discoverability | Local SEO, schema.org Dentist and FAQ nodes, llms.txt generated from the CMS |
| Quality gates | PHPStan level 7, automated tests, WCAG 2.1 AA, reduced-motion support |
07 — FAQ
What buyers ask about a Laravel clinic site and CMS.
Why build an owned site when aggregators already send patients?
Because on an aggregator the clinic is a row, ranked by someone else's logic, one tap from a competitor, and the introduction is rented rather than owned. An owned site is where the clinic's own credentials, doctors and tone do the work — and it is the asset that structured data, local SEO and AI answers can all point at. The aggregator listing still helps; it just should not be the only thing that exists.
Why do doctor profiles centre the site rather than services?
Because patients book a person, not a procedure. Each of the seven dentists has a dedicated profile covering credentials, specialisations and treatment philosophy, and service pages and patient case studies link back to whoever actually delivers the treatment. Trust accrues to a named doctor far faster than to a clinic brand — and it gives the site seven entry points instead of one.
What is llms.txt, and why would a dental clinic need one?
It is a machine-readable description of the clinic, its doctors and its services, served at a predictable endpoint. Patients increasingly ask an AI assistant for a dentist rather than scrolling a results page, and those systems answer from whatever structured, authoritative source they can read. Most local businesses expose none and are simply absent from the answer. Tooth Print's is generated from the CMS on request rather than maintained by hand, so it cannot drift out of date when a doctor profile changes.
How do patients actually get in touch?
By tapping. Call, WhatsApp and get-directions stay within reach on every page, including individual doctor profiles, so a patient who arrives on a specific dentist can reach the clinic without navigating to a generic contact page. There are no mandatory forms and no gated content in the path.
Can the clinic change the site without calling a developer?
Yes. Services, doctor profiles and patient case studies are all editable through a Filament admin panel the clinic owns. Underneath it, PHPStan static analysis at level 7 and a PHPUnit test suite guard the platform, so routine content edits cannot quietly break the site.
What does a clinic site like this cost, and how long does it take?
This is the smallest engagement on the page: a focused build in the 8–12 week band, covering the site, the CMS and the SEO and AI-discoverability stack in the table above. We work in two-week sprints, so there is working software to look at from week two rather than a reveal at the end.