Egypt already has Vezeeta for doctors. What it doesn't have is a dentistry-first booking layer that's actually live-synced with the clinic's real calendar — the operating system dentists already use, Dentolize. Dental Map closes that loop: patients book a slot, and the slot becomes an appointment in the clinic's own schedule. No receptionist reconciliation. No phone tag.
17,000+ doctors in Egypt · 110k bookings/month. Dominant for GPs and specialists. Dentistry coverage is shallow; bookings flow to leads, not to clinic software.
~5,000 dentists across 29 countries. Patient charts, scheduling, WhatsApp bot, billing, inventory. No public API. The integration surface we'll negotiate our way into.
Arabic-first patient marketplace. Live slot availability computed from the dentist's own Google Calendar. Booking writes straight back. The loop closes itself.
The ambitious path. Patients see a dentist's actual open slots — not a lead form.
Clinics connect a Google Calendar per dentist. Where Dentolize mirrors to Google, the loop is automatic. Where it doesn't, the receptionist copies once per booking during the pilot.
One city, all dentistry subspecialties. Prove the loop before going nationwide.
Matches Egyptian market reality. English available via header toggle.
Phone is still required at booking — the clinic needs to reach the patient. OTP login can come in v1.1 if signup dropoff is high.
One codebase. Installable from the browser. No app-store friction.
Zero friction for clinics. Monetize post-pilot via commission or subscription once liquidity exists.
SSR for SEO on dentist profiles. Supabase collapses Postgres + Auth + Storage + Realtime into one managed surface.
RSC + SSR so every dentist profile is Google-indexable. "Dentist in Nasr City" long-tails are Vezeeta's #1 acquisition channel — we need the same.
Postgres (relational queries: "dentists taking Insurance X, area Y, slot Z"), auth, storage, row-level security, realtime — one service, a weekend of wiring, not a month.
The only integration surface we can reach without a Dentolize partnership. The dentist already owns the OAuth consent. We read free/busy, write events back.
Google Calendar is the canonical sync surface. Clinics that already mirror Dentolize ↔ Google get a seamless loop. Clinics that don't: their receptionist copies the booking into Dentolize once — ≤30 seconds per booking — aided by a one-click copy patient details button. Tolerable at pilot volume.
Pitch Dentolize for a real partnership with demonstrated patient-side liquidity. If they won't deal: a tiny opt-in desktop helper that pushes bookings into Dentolize via the clinic's own session. No credential-harvesting. No ToS-breaking.
Next.js 15 scaffold with next-intl (Arabic RTL + English). Supabase: Postgres schema, email/password auth, storage buckets, RLS policies. Tailwind + shadcn/ui with custom palette. Patient shell, dentist shell, auth pages.
Clinic/dentist profile editor. Google Calendar OAuth start + callback. Encrypted token storage. Working-hours editor. The availability engine (lib/availability/) that computes open slots from working hours minus Google busy.
Search (specialty + area + date + insurance + fee range). Dentist profile page, SSR'd. Slot grid. Booking flow with inline email signup. Booking server action: database + Google Calendar event + patient + clinic emails, atomic.
Post-appointment auto-transitions (Vercel cron). Review flow behind RLS. Ops console: invite clinics, view bookings, dispute tools. Arabic translation QA pass.
SEO: sitemaps, schema.org MedicalBusiness + Physician markup, localized URLs. Seed 20–50 Cairo clinics. Soft launch to a small patient list (WhatsApp groups, FB). Sentry, Supabase logs, daily funnel dashboard.
| Risk | Mitigation |
|---|---|
| Dentolize ↔ Google sync is absent or clunky for some clinics. | Phase-1 fallback: receptionist manual mirror, ≤30 s per booking. One-click copy button. Acceptable at pilot volume. |
| Email/password auth is weak for Egyptian patients who rarely use email. | Phone is mandatory at booking time regardless of login method. Add phone OTP login as v1.1 if signup dropoff is material. |
| SMS / WhatsApp reminders matter for no-show reduction. | Email-only for MVP. WhatsApp Cloud API if week-5 time permits; otherwise phase 2. |
| Patient liquidity — classic chicken/egg. | Sign 5–10 clinics before any patient acquisition. Paid FB + Google for first 500 Cairo patients. |
| Google Calendar quotas or webhook breakage. | Push notifications (watch endpoints) + refresh tokens. Quota is generous at 50-clinic scale. |
| Arabic RTL bugs in Tailwind / shadcn components. | next-intl + dir="rtl" wrapper. Component-by-component audit. Half-week QA budget in week 5. |
Before the pilot opens to more than two clinics, the following must all pass. Any red, we don't ship.
Dentist onboarding. Connect Google Calendar on two test dentists. Set working hours. Availability grid matches expectations (working hours minus Google busy).
Patient booking. In incognito, search "dentist in Nasr City," pick a dentist, pick a slot, sign up with email, book.
Write-through loop. Booking appears in (a) our appointments table, (b) the dentist's Google Calendar, (c) patient's email, (d) clinic admin's email.
Dentolize loop. For a clinic with Dentolize↔Google sync on, event appears in Dentolize within its SLA. For a clinic without: receptionist confirms ≤30 s copy time.
Review gate. Posting a review from a non-booking patient is rejected by RLS. Posting from the booking patient after completion succeeds.
i18n. Locale toggle flips direction and copy cleanly. RTL mirror layout has no leaking LTR components.
SEO. View-source on a dentist profile shows localized title, description, and schema.org JSON-LD. Sitemap submitted to Search Console.
Explicit YAGNI. Everything below is tempting. None of it is on the MVP path.