Building DocDoc: real-time doctor booking, built then sold in Palestine

Booking a doctor in much of the region still meant calling the clinic during office hours, hoping someone picked up, and waiting. The care was fine; the appointment was the bottleneck. DocDoc was built to make booking a visit as quick as booking anything else. We were on the founding team and designed and built the whole product, and it was later sold to a healthcare company in Palestine. Here is how it came together.

The problem: the appointment was the bottleneck

Everywhere we looked, the friction wasn't the consultation — it was getting to it. Patients called during narrow office hours, played phone tag, and had no visibility into which doctor had a slot when. Clinics, meanwhile, ran their schedules on paper and phone calls. The whole experience was stuck in a pre-digital workflow that every other part of people's lives had already left behind.

Discovery: availability is the whole product

Our discovery sprint kept returning to one thing: real-time availability. If patients could see genuine open slots and book one instantly, and if doctors could publish and manage those slots without friction, the rest of the product fell into place. So we scoped a tight first version around exactly that loop — find, book, confirm, remind — and left everything else for later.

Architecture: real-time, Arabic-first, low-bandwidth

We built DocDoc on Flutter for a single iOS and Android codebase, with a Node services layer, Postgres for the scheduling core and WebRTC where consultations needed to happen in-app. The defining challenge was keeping availability genuinely real-time — a slot taken on one device had to vanish on every other one immediately, or the whole trust model breaks. The pieces that carry it:

• Find a doctor — search by specialty, location and genuine availability, not a stale directory.
• Book in seconds — real-time slots with instant confirmation, so there's no call-back limbo.
• Reminders — visit reminders that cut no-shows for patients and clinics alike.
• Records — a simple history of visits, kept in one place for the patient.

Design: calm, clear, and trustworthy

Health is an anxious context, so the interface had to do the opposite of most apps fighting for attention — it had to feel calm. We kept the path from symptom to booked visit short and unambiguous, made availability and confirmation impossible to misread, and built it Arabic-first and low-bandwidth from the first frame so it worked on the networks and phones people actually have.

The outcome: built end to end, then sold

We designed and built DocDoc end to end as part of the founding team. The product was later sold to a healthcare company in Palestine that took it forward — a clean outcome, and proof that a focused, well-built product holds its value. We carried the lessons about real-time systems and trust-first design straight into the work that came after.

What we'd do again

Three calls held up. Anchoring the entire product on real-time availability instead of treating it as a feature. Designing for calm and clarity, because health is not the place for clever interfaces. And keeping the first version tight enough to ship, prove and ultimately pass on. If you are building a booking product in healthcare, those are the decisions we'd tell you to get right first.