Context
JOBS Clinic is a healthcare app built to replace the friction of in-person clinic visits with a single mobile experience: booking doctor appointments across specialties — OB/GYN, aesthetics, mental health, sexual wellness, and more — ordering and getting prescription medication delivered, and monitoring ongoing health metrics, all from the phone.
A meaningful part of the app is built specifically around maternal health: the Mother Passport feature acts as a running, organized medical record for expecting mothers and their children — tracking pregnancy milestones, menstrual cycle data, and due-date calculations, alongside broader monitoring like blood pressure and heart rate.
Because a large share of the value in a healthcare app comes from real-time interaction with a provider — not just browsing content — the app also had to support live video, audio, and chat consultations responsive enough for a genuine doctor-patient conversation, not a laggy video call bolted onto a booking app.
I built this end-to-end across Android and Flutter as an equal co-owner alongside Haris Akram, who held the same Senior Android & Flutter Engineer role.
The Product
A tour of the surfaces referenced throughout this case study — home and specialty divisions, a doctor's profile and booking flow, the appointment calendar, Mother Passport, health monitoring, medication ordering, bookings, and account.
The Problem
- Multiple distinct domains, one coherent app. Appointment booking, medication ordering/delivery, and health-metric tracking are three fairly different problem spaces — each with its own data model and flow — that still needed to feel like one consistent product rather than three bolted-together modules.
- Maternal health needed more than a form. Pregnancy tracking isn't a single data point; it's milestones over time, cycle history, due-date math, and a growing set of medical records per child — all of which needed structure that would stay usable as a family's history grew.
- Real-time communication is unforgiving. Video, audio, and chat between a patient and a provider have a very low tolerance for lag, dropped frames, or delayed messages — a consultation that stutters undermines trust in the entire app, especially in a healthcare context.
- Two engineers, one codebase. Building end-to-end with another senior engineer meant the architecture had to support clean parallel ownership of different modules without stepping on each other's work or drifting into inconsistent patterns.
What I Built
Booking, medication, and health-metric modules
Built out the app's three core pillars: the doctor appointment booking flow (browsing specialties, selecting providers, scheduling regular or VIP slots), the medication ordering and delivery flow (prescription refills through to doorstep delivery), and the health-metric tracking module (blood pressure, heart rate, and related vitals) — designed as distinct but consistent modules within the same app architecture, sharing common patterns for data handling and navigation rather than each being built as a one-off.
Pregnancy and family health record
Implemented the Mother Passport feature end-to-end: pregnancy milestone tracking, menstrual cycle monitoring, and due-date calculation, alongside a structured, ongoing medical record per child so a family's health history stays organized and accessible over time rather than scattered across appointments. This feature effectively turns the app into a longitudinal health record for expecting and new mothers, not just a one-time booking tool.
Live video, audio, and chat via WebRTC + Firebase
Implemented live video calls, audio calls, and chat between patients and providers using WebRTC for the real-time media transport and Firebase for signaling/backend coordination, tuned to hit sub-200ms latency — the threshold where a consultation feels like a real conversation rather than a call fighting against lag.
Built and shipped as a two-senior-engineer effort
Working alongside another senior engineer on the same codebase, we split ownership across the app's modules while keeping shared architecture and conventions consistent, so the end result reads as one coherent app rather than two engineers' separate implementations glued together — something that matters as much for long-term maintainability as it does for the initial build.
Why These Choices Mattered
Treating booking, medication, and health tracking as siblings under one consistent architecture — rather than three independent mini-apps — kept the codebase maintainable and made it easier for two engineers to work in parallel without conflicting patterns.
Pregnancy and family health data accumulates over months and years; building it as a structured, queryable history from the start avoided the common trap of health apps that only handle "right now" well and fall apart as data piles up.
Choosing a transport built specifically for low-latency peer-to-peer media, rather than a generic chat/streaming stack repurposed for calls, was what made the sub-200ms target achievable — latency in a healthcare consultation isn't just a UX nicety, it directly affects whether a remote diagnosis conversation actually works.
On a two-senior build, the real risk isn't lack of skill on either side — it's architectural drift between modules built independently. Keeping conventions aligned across both engineers' work was a deliberate, ongoing effort, not an afterthought.