Oltigo
The quiet operating system for medical clinics in Morocco. A public booking page, a unified week view, an encrypted patient vault, and appointment reminders over WhatsApp, in Darija, approved by Meta.
Outcome
Multi-tenant SaaS for Moroccan clinics: online booking, encrypted patient records, and WhatsApp reminders in Darija.
- Live in production at oltigo.com
- Operational in one afternoon: account, configuration, booking page, first reminders
- 10 Darija reminder templates approved by Meta. Patients confirm by replying « OUI »
- Sub-200 ms P95 latency server-side, measured over rolling 30-day windows
- Designed around Loi 09-08 (CNDP) data-handling requirements; final compliance obligations remain subject to each clinic's legal review
Founder-built product in early rollout with Moroccan clinics. The figures above are measured launch metrics; clinic-impact numbers get published here as they're collected.
Data protection, encryption and Meta's template approval process, handled end to end by the same person who wrote the code.
THE LIVE PRODUCT
A real screenshot captured from the live product, no mock UI. Click it to open the site itself and judge the real thing.
The problem
Clinic managers in Morocco juggle three WhatsApp groups, a paper appointment book and a shared Google Sheet for patient files. No-show rates stay high, patients call to confirm appointments they already booked, and sensitive records live in chat history, with real legal exposure under Morocco's Loi 09-08.
What I built
One platform per clinic, isolated at the database level. Patients book from a public page, no app to install. Reminders go out automatically over WhatsApp in Darija; patients confirm by replying « OUI ». Sensitive patient fields are encrypted at the application layer with AES-256-GCM, access restricted to the clinic's team. Each clinic gets its own subdomain with row-level security: the clinic next door doesn't exist for yours.
How it went
Shipped UI
No staged wireframes here: this is the actual product as it runs today, captured from production.
- One accent color (#2fbf8f) doing all the signaling work
- Real empty, error and loading states designed before the happy path
- Type and spacing tokens shared between marketing and product surfaces
Engineering details — architecture, APIs, data and stack
Architecture
- One subdomain per clinic (cabinet-a.oltigo.com): strict tenant isolation by design
- Row Level Security in Postgres: every query filtered by clinic, with automated tests covering cross-tenant reads and writes
- WhatsApp Business API with Meta-approved Darija templates, sent before every appointment
- Sensitive patient fields encrypted at the application layer with AES-256-GCM; access scoped to the clinic's team
APIs
- WhatsApp Business API (Meta)
- Public booking API
- Activity analytics
Database
Postgres: tenants, practitioners, appointments, encrypted patient records
Authentication
Team-scoped access per clinic; separate patient entry points, no shared surface
Stack
Measured quality
Self-reported — how these were measured
I ran Lighthouse myself against the production builds. Your device, connection and Lighthouse version will move these numbers.
Performance
Sub-200 ms P95 latency on the live platform, measured server-side over rolling 30-day windows. Booking flows work on any phone, no app install.
SEO
Trilingual surface (FR · AR · EN) with localized metadata, so clinics get found in their patients' language.
Accessibility
Booking is a short, plain-language form, designed for patients, not administrators.
