Medical Practice Management Platform
The system a Jakarta family practice runs on every day.
Watch it run
02 TAKESEvery feature, step by step
06 FEATURES · 21 SCREENS · OPEN ONEA day at the practice
04 STEPSWhat the doctor sees when she sits down, and how she gets from the day, to the week, to a new booking.
Seeing a patient
05 STEPSFrom the patient list to a written-up consultation — the path this software exists to shorten.
Issuing a document, start to finish
04 STEPSFive document types, one shared template package, and a preview that is literally the file that gets sent.
WhatsApp, and how much the assistant may do
03 STEPSPatients message the practice on WhatsApp. Every contact has its own leash, and the assistant hands over anything it should not be answering.
Getting paid, and getting reimbursed
04 STEPSTwo different problems: chasing what patients owe, and filling in what insurers demand before they pay.
The parts nobody demos
01 STEPWhat the assistant is allowed to tell patients, when the practice is open, and where each kind of notification lands.
All captured from the real app running in its demo mode, which starts with no database credentials at all: it skips the login and physically cannot reach the practice’s data. Every patient, message, invoice, claim and document here is invented — the eight demo patients the app ships with, plus stand-in rows written for the screens that normally read from the live backend, so they could be photographed without touching anything real. The insurance form is likewise a mock-up, drawn for the demo from an insurer that does not exist. The doctor’s own details are blurred wherever they appear: her name, the hospital she practises at, her registration and licence numbers, phone, bank accounts, email and signature seal. Beyond that nothing has been retouched — every layout, control and state is the software as it ships.
I spent three years as a medical assistant digitising patient records by hand. This is the software that replaced that job. It started as something I built for myself to use, and the practice now licenses it on a paid monthly subscription — patients, appointments, billing, insurance claims, clinical documents and messaging in one place, on the web and on Android.
How it’s put together
Built with
- PERIOD
- June 2026 — Present
- ROLE
- Solo — design, build, ship, support
- SOURCE
- Private repository — it holds real clinical data. Walkthrough available on request.
The hard parts
12 NOTESA TypeScript monorepo on npm workspaces: a React dashboard, a second Android app, a shared package holding the document templates, and a standalone ingestion tool — 66 serverless Deno edge functions and 31 PostgreSQL migrations behind them, covered by 269 unit tests.
The browser only ever holds the read-only anon key. Every write goes through an edge function, so the privileged path is a list of 66 named operations rather than a database the client can reach — a stolen key from a laptop in a consulting room reads nothing it should not and writes nothing at all.
An insurance claims module that fills insurers’ own reimbursement forms rather than producing a lookalike: PDFs with real form fields are filled by name, and scanned or photographed ones by a percentage-based coordinate map that survives a re-scan at any size.
Nothing is signed until she has read it — the signature and stamp go on only at the moment of approval, so a signed claim she has not seen cannot exist.
Documents carry a server-assigned sequential number issued from an atomic counter, so paperwork cannot be forged or duplicated.
The document templates live in one shared package because they used to be a copy each. The dashboard learned to take the signature and stamp from Settings and the phone app did not, so the same prescription carried a different seal depending on which one produced it. Sharing the code was the fix; the bug is the reason the package exists.
A second Android app, the practice’s own “Documents”, that writes one document and shares it and can do nothing else — installed alongside the dashboard, with its own icon and session, for the times she needs a prescription on a phone and nothing more.
WhatsApp Business through Twilio for bilingual invoices, prescriptions, reminders, appointment booking and claim intake, in English and Bahasa Indonesia.
Notifications land where they can actually be seen: an in-app bell on the laptop, because the dashboard is already open and a popup would interrupt a consult, and Android push through Firebase for the phone, which is usually closed. Every kind can be switched off per channel.
Claude runs as an eight-tool assistant that books appointments, produces documents and drafts consultation reports and medical certificates — always proposing, never committing, until she approves.
Patient files are never committed and never cached locally. Google Drive is the authoritative store through a service account; Supabase holds only the structured data extracted alongside it.
The tests are pure logic by design — scheduling, date maths across the Jakarta timezone, document rendering — and linting is deliberately kept out of the build, because a lint error should never be the reason a document cannot be issued.
Want the parts that aren’t on this page — the architecture arguments, the things that broke, a live walkthrough?