Currently doing an MSc at Politecnico di Milano
Designer with specialisation in Product, Motion, AI and Research
Previously at
Product Designer I, 2024 to 2026Late 2024 to 2026Shipped
Making Care Plan honest about what it costs and what it gives
B.Des, IIITDM JabalpurConcept
Redesigning a station master's control panel
Products I am building, freelance and side projects.
Open to new roles
DentFlow
AI build · HealthcareOngoing
One patient visit, from the phone call to the invoice, designed as a single flow and built with AI for a working dental clinic.
I spent a day at the clinic before I opened an editor. I followed one patient, a root canal follow-up, from the first phone call to the receipt.
Her booking was in a paper diary. Her message was in WhatsApp. Her chart was a paper card. Her prescription was on a pad. Her bill was a row in a spreadsheet the receptionist filled in at six, from memory and sticky notes.
Nothing was broken. It was five tools, and a person carrying the patient between them.
Before any screen, I wrote the day as a line and marked where the patient got dropped.
Book, check in, wait, chair, chart, treat, bill, follow up.
Three drops showed up. At check-in, the receptionist re-asked things the diary already knew. At the chair, the dentist walked to a cabinet for the card. At the end, the price quoted was not always the price billed. I decided the product had to fix those three and could leave the rest alone.
Most clinic software is built around the patient: a record you open and edit. But the day does not run on records, it runs on visits.
So the visit became the main object. One encounter holds the check-in, the diagnosis, the treatment and the bill, in that order, as steps. Open it and you always know where you are and what is next. Everything else hangs off it.
The front desk’s real question is “who is next, and which chair is free?” So the home screen is that: patients wait in a column, chairs sit beside it, and you drag a card to a free chair to start the visit.
The chart and the treatment plan can disagree, so I wrote down who wins. A treatment writes its own mark on the chart. A mark drawn by hand never creates a treatment. The rule runs one way only.
It is a product decision, not a technical one. A dentist can sketch freely without accidentally billing a patient.
The first version was a quick prototype on Emergent, to test the flow with the clinic. It proved the idea and was not a base to grow. On 24 March 2026 I started again in an empty Next.js project, with Claude Code.
I did not start with code. For each big piece, like the dental chart, I wrote the spec first, then a plan, then let the AI build against it. I made the calls on the flow, the rules and the screens. The AI wrote most of the code, and I reviewed it as if a stranger had sent it.
The rest is habit. Rules live in a file the AI reads every session, CLAUDE.md, with a numbered list of known fixes. It has 29 now. Each one is a mistake the project should not make twice.
On 17 September a change passed my checks, then failed after it deployed. My local verify command was not running everything the CI did. I did not just fix the change. I fixed the gap: verify now runs the same guard as CI.
That guard is also what keeps each clinic’s data its own. It fails the build if any feature reaches around the clinic-scoping layer, because a slip there would be a silent leak, not a visible error.
DentFlow runs two ways: in the cloud, or on a clinic’s own Windows PC with Docker, because some clinics will not put patient records online. By September it was 238 commits, 75 data models and 34 API routers, with tests on the routers.
At the clinic, check-in takes under a minute where it used to take about four. The six o’clock spreadsheet is gone, because the bill is already built by the time the patient stands up.
A context-aware AI assistant using LLM tool use, so a dentist can say “book her follow-up in two weeks” and the visit appears. Local models are the first option, so patient data can stay on-site under India’s DPDP rules.
