doctor-buddy-app
A pocket assistant for the ward
A quick-reference companion app for doctors on the floor.
Tools I used
How it started
A homeopathic practice runs on repertorisation, and repertorisation on paper is slow enough to shape the whole consultation.
What actually happened
Doctor Buddy is the largest thing in this collection and the only one with a serious database behind it. The schema is the product: kent_rubrics with English and Telugu text, remedies classified by kingdom, a rubric_remedies junction carrying grades one to three, case_symptoms joining a case to its rubrics, and repertorization_results holding the aggregated scores. Roles are handled properly — a user_roles table and a has_role function drive row level security, so a patient and a doctor see genuinely different data rather than differently rendered pages. Capacitor is configured for Android and iOS, which means the same web build is intended to run as an installed app. Thirteen routes exist, including separate patient and doctor dashboards, prescriptions and case taking.
Moments that changed the build
- Me: "Doctors and patients cannot see the same rows." → Roles moved into their own table and became a database rule, not a UI check.
- Me: "The rubrics need Telugu." → Bilingual columns in the schema itself, so language is data rather than translation done later.
- Me: "Can this be a phone app?" → Capacitor wraps the same build; there is no second codebase.
What broke
Three ways in. A shared auth page plus separate doctor and patient logins overlap, and the repertorisation scoring lives in the database while the interface around it is still vague about when a total is calculated.
What I learned
Permissions belong in the database. If the rule only exists in the screen, it does not exist. And a schema that models the actual method — rubrics, grades, totals — carries more of the product than any page does.
The ebook from this project
- Read it
The doctor-buddy-app Story
A pocket assistant for the ward
Ebook · $9.00