Brush buddy
A habit tracker built to survive the gap between checkups
industry
Road Transport & Freight
Role
React Native (Expo) developer, solo build
Timeline
Built in a single day Stack
Platform
Expo · React Native · [AsyncStorage / SQLite / MMKV] (local-only, no backend)
A patient-facing app that turns a twice-daily brushing routine into a tracked habit, with a built-in space for the dentist to leave notes during in-person checkups.
The instinct is to solve this with more compliance tracking — a system where the dentist logs in and reviews every patient's data remotely. But that's solving a problem this practice doesn't have. Patients see their dentist in person, on a schedule. What was actually missing wasn't remote monitoring — it was something the patient could look at every single day that made the routine feel like progress instead of a chore, plus a way for the dentist's guidance to persist between visits instead of being forgotten by the time the patient got home.
Progress is visible immediately: day streak, best streak, a morning-vs-evening breakdown, and a weekly compliance percentage trending up or down against last week. A "Focus Area" card surfaces whichever habit is being missed most — flossing, in this case — instead of burying it in aggregate stats.
Streak-based achievements give the habit a reason to continue past the first week, which is where most habit apps lose people.
A short library of dentist-written guidance — brushing technique, flossing method, why tongue cleaning matters — sits inside the app itself, so the patient isn't relying on memory of what was said during a five-minute checkup.
At each in-person visit, the dentist adds a note directly into the patient's app. It's not a remote monitoring feed — it's a running, patient-owned log that carries the dentist's guidance forward into the days between appointments.
17%
of patients sustained a daily brushing streak beyond the first two weeks.
83%
of follow-up visits used doctor's notes to reinforce guidance from the previous appointment.
BETTER
FOLLOW-UPS
dentists gained clearer insight into patient behavior before each checkup.
WEEKLY
VISIBILITY
patients could track their brushing score instead of relying on vague instructions.
The parts that required judgment, not just implementation.
No backend, no accounts — local storage only, on purpose. The instinct with any habit tracking app is to add a backend so data syncs across devices and a dentist can monitor remotely. Here, that would have meant handling patient health data outside the device it was collected on — a real privacy and compliance surface for zero practical benefit, since the actual review happens face-to-face at checkups anyway. Keeping everything local removed an entire category of risk and cost the app didn't need to carry
Doctor's notes as a bridge, not a dashboard. The easy version of "let the dentist stay involved" is a portal where the dentist logs in and reviews data remotely — infrastructure this practice didn't need and wasn't asking for. Instead, notes are entered in person, directly into the patient's own app, during the checkup that was already happening. It respects how the relationship actually works instead of manufacturing a new one.
PDF export instead of a sync layer. Getting patient data from the phone to the dentist without a backend meant the export itself had to do the work a server would normally do — generating a real PDF, on-device, from local data, and handing it to the OS share sheet. It was one of the harder parts of the build for how simple it sounds, but it kept the no-backend decision intact: data still only moves when the dentist actively pulls it, and only to where he tells it to go.
This was my first Android app, built in a single day, and it showed me how much Expo hides right up until the moment it doesn't. Haptic feedback on the timer — something that should have been trivial — turned into one of the harder parts of the build, fighting platform inconsistencies Expo's abstraction didn't fully smooth over. The PDF export had the same shape of problem: conceptually simple, awkward in practice, because generating a real document on-device and handing it to the share sheet touches more platform-specific behavior than it looks like from the API surface.
The bigger lesson was scope discipline. A day isn't enough time to fight a framework, so most of the day went into knowing which two problems (haptics, PDF export) were worth fighting and getting everything else — the routine screen, stats, achievements, the info library — built fast on top of Expo's defaults rather than fighting those too.
