The Dental Specialists is a specialist dental group running three branches across Hyderabad, a flagship in Banjara Hills plus branches in Kondapur and on Dharamkaram Road. Like most clinics its size, its entire clinical record lived in a paper case file booklet: medical history, the tooth by tooth examination, treatment plans, estimates, payments, prescriptions, discharge notes.
When I sat with the clinic, the cost of paper was everywhere. The booklet could not travel between branches, so a patient treated in Banjara Hills was effectively a stranger at Kondapur. Nobody could say who edited a plan or approved a discount. Finding an old case meant digging through a filing cabinet. And under India's data protection law, a cabinet cannot evidence consent, access control, or retention at all.
The founder also had no real time view of the business. Revenue, dues, plan conversion, and low stock across three branches were not visible in one place to the person running it.
So the mandate was clear. Replace the booklet with a staff only, multi branch app: role based access, a real audit trail, approval workflows, an interactive tooth chart, search across branches, clean printouts, and a grounded AI copilot, delivered as a live product the clinic runs itself.
The most novel piece, and the one with the most ways to go wrong, is the case copilot shown in the hero. It is a retrieval augmented generation (RAG) pipeline, and it was the highest risk feature, to me the real test of AI product judgment. An assistant that invents clinical claims, or that leaks a patient's name to a third party model, is worse than no AI at all. So I designed the four steps so a wrong or unsafe answer is structurally hard, not just discouraged by a prompt.
1 · Retrieve
A single ranked search over the clinic's own records, using Postgres full text and trigram matching, returns the best matching cases. That search is also the access gate: clinicians and admins only, everyone else gets a permission error.
2 · Protect identity
Every retrieved case is stripped of name, phone, code, and email and given an opaque Case N label before anything reaches a model. The map back to the real patient stays on the server.
3 · Generate, grounded
If nothing was retrieved, it declines without ever calling the model. When it does answer, the model is restricted to the cases provided and must cite each clinical claim.
4 · Cite and cap
Citations are checked against the cases actually used and mapped back to real IDs for the clinician. Model, tokens, and cost are logged, under hard rate and cost caps.
Before building anything, I wrote down what success had to look like, so this would be judged on outcomes, not on a demo that happened to go well. Each criterion later became part of the test suite.
- A user of each role sees exactly their permitted actions, enforced by row level security, not just hidden buttons.
- The full patient journey works end to end, from registration to a printable case sheet.
- Every change is captured in an immutable audit log.
- Any staff member can search and retrieve any patient or document across all three branches.
- The copilot answers natural language case questions grounded in the records, under hard rate and cost caps.
- The product is live, hosted in the India region, and installable as a PWA.
Every one of these was met at delivery.
Every screen below uses sample data, never real patient records.
A calm, serious front door
The whole clinic signs in here. There is no public sign up. Accounts are created by an admin, because this is staff only software that holds patient records, and I wanted that boundary to be obvious from the first screen.
I had the visual language, which we called Clinical Calm, designed and signed off in Figma before the build began, so every screen had a coherent target from day one. The compliance promise sits right in the footer.
The front desk runs the day from one screen
The receptionist opens straight into today at their branch: who is booked, who is checked in, who is in the chair, what is overdue, and who was just registered across all three branches.
Register, take a payment, or search, the four things that fill the front desk day, are one tap away. I kept clinical data view only for this role, so the front desk is fast without being able to touch findings.
One patient identity across three branches
Registration takes under a minute and generates a unique patient ID on save, so the same person is recognised at any branch and is never entered twice. A database backed duplicate guard enforces it.
A quick register path back enters the old paper files, so the clinic could move off paper without stopping operations for a day. Every field is audited.
The chair sees what needs attention
The doctor lands on their clinical day: their appointments, who is in the chair now, and the treatment plans waiting on a senior sign off.
I designed each role to land on a different home screen tuned to its job, so the work that needs you today is the first thing you see, not something you have to go hunting for.
The tooth chart, made interactive
The clinical centerpiece is a real FDI tooth chart for adult and child teeth. Click a tooth and tag the problem, the surface, and a note, and the chart colour codes findings by category.
I had this built first, because it is the hardest piece and the one a dentist judges first. From these findings the doctor builds a treatment plan and proposes it for senior approval, then it moves through its lifecycle to completed.
Where revenue stops leaking
Estimates build straight from the treatment plan and the total is always derived, never typed by hand. A discount stays pending, with no price change, until a senior or the founder approves it with a reason on record.
And you cannot approve a discount you requested yourself. That rule lives in the database, not in a hidden button, which is the difference between a real control and a polite suggestion.
Stock that protects safety and money
Every item is tracked per branch and per batch, with expiry dates, reorder levels, and low stock, expiring, and expired flags. The oldest safe batch goes out first.
Dispensing a prescription decrements the right batch automatically, so the ledger and the shelf never drift apart, and branches can move stock to each other instead of over ordering at every location.
This is patient data, so from the first spec I treated it as production healthcare software, not a demo. The security and compliance are structural. A feature physically cannot touch data without going through an audited, role checked path, and the screen is never the security boundary.
Security at the database
Row level security and server side write functions check the caller's real role on every change. Retrofitted security has holes, so I made it the foundation the whole product is built on.
An immutable audit trail
Every change records who, their role, the field, the value before and after, and when. It is partitioned to stay fast as it grows, and the founder and developer can read it directly.
Approvals that cannot be gamed
Discounts and treatment plan sign offs run through one reusable approval flow: proposed, pending, approved or rejected, and no one can approve their own request.
Patient data safe by construction
Private storage with short lived links, money stored as exact paise so totals never drift, caches purged on logout, and a scrubber that strips patient data from error reports before anything leaves the app.
India resident by design
Records, accounts, and patient media all run in the Mumbai region, with the app pinned to the same region, so data residency under the DPDP Act is satisfied cleanly.
Two diagrams carry most of the product thinking. The first is the system: how a request travels from staff to data and back, and where the safety lives. The second is the copilot's path, where the guardrails are the route itself, not a note in a prompt.
I ran this the way I run every client engagement. Discovery first, then a roadmap broken into vertical slices, each shipped through a repeatable plan, build, validate, review, commit loop.
Discovery produced a brainstorm that locked the hard decisions early: the five roles, senior approval for discounts, FDI tooth numbering, three branches, a single backend, and removing patient identity before any AI call. That became a roadmap of six executable specs, each an end to end slice that left the product demonstrable at every step.
I de risked the two hardest, most visible pieces first, the interactive tooth chart and the grounded copilot, each with a simpler fallback in reserve, so the demo path was never at risk while the routine work was filled in. Independent slices ran as parallel workstreams and merged back to a releasable trunk, and every slice passed a code review and a dedicated security and privacy pass before it landed.
I held a production bar, not a demo bar. Quality was proven by automated tests run together, not by spot checking screens.
For the first time the founder can see the whole business at a glance: revenue and collections, new patients, plan conversion, low stock, the discount approval log, and today's activity across all three branches, with a branch filter to drill in.
Decisions move from gut feel to data. A branch that is underperforming, a conversion rate slipping, or stock about to expire is visible early enough to act on.
A few more of the pieces that make it a complete system rather than a demo.
All six specs were built, tested, and handed to the client, on plan. The result is a complete, deployed product, live in the India region and installable as a PWA, that runs the full patient journey end to end with every change audited and a grounded copilot on top.
- One system across three branches. Records and search finally travel between Banjara Hills, Kondapur, and Dharamkaram Road.
- Safe delegation across five roles, with approvals and the no self approval rule wired into the database, not staff discipline.
- Provable compliance: India data residency, encryption, consent capture, long retention, and an audit trail that answers who changed what, when.
- Revenue protection through controlled discounts, visible dues, per branch daily cash close, and derived totals.
- Patient safety through point of care allergy alerts and inventory that prevents stock outs and expired material.
- Practice visibility for the founder, across all branches, in real time.
- A foundation for AI, with the search backbone and a reserved vector store ready for the next phase semantic copilot.
I directed the full stack build by giving AI coding tools tight specs, tests, and review, the same way I ship every product I take on.
- Ran discovery with the clinic, the founder, doctors, and front desk, and turned the paper booklet into a buildable product with measurable success criteria.
- Designed the role model, the permission matrix, and the governance the whole clinic runs on: approvals, the no self approval rule, and the audit trail.
- Designed the RAG copilot to be grounded, identity safe, cited, and cost capped, which was a product and safety design problem, not just a prompt.
- Owned delivery end to end: a roadmap of six vertical slices, parallel workstreams, quality gates, and an on plan handover.
- Built and shipped the production system myself by directing AI coding tools across the full stack.
Want the full walkthrough?
I am happy to demo The Dental Specialists live and talk through the product decisions, the governance model, and how I scoped and shipped it.