Healthcare · 2026
Clinic management system and patient app
One system for a multi-specialty clinic group: reception books and checks patients in, doctors write visit notes and prescriptions, billing handles cash and insurance, and patients book, pay and see their results from a mobile app.
Built by
- Client
- Withheld at the client’s request
- Users
- Reception · Doctors · Billing · Patients
- Platforms
- Web · iOS · Android
- Typical timeline
- 4–6 months
- Squad
- 8 people · 6 disciplines
Technologies
- Laravel
- Next.js
- Flutter
- PostgreSQL
- Redis
- Firebase (FCM)
- Payment gateway
- Docker
The product
10 images01
Brief
Paper files, phone bookings and a queue at reception.
Context
The group has several specialties across a few branches. Each branch kept its own booking book, and patient files moved between rooms on paper.
Problem
Double bookings, lost files, insurance claims rejected for missing data, and patients waiting on the phone to book.
Goals
- One schedule for every doctor and branch
- A medical record that follows the patient
- Insurance claims complete the first time
- Booking and payment from a phone
02
Team
The squad behind it.
| Tech leadArchitecture, data privacy and insurance integrations | ×1 | Architecture, data privacy and insurance integrations | Senior | |
|---|---|---|---|---|
| Product designerReception, doctor and patient flows | ×1 | Reception, doctor and patient flows | Senior | |
| Frontend engineerReception, doctor and billing web app | ×1 | Reception, doctor and billing web app | Senior | |
| Mobile engineerPatient app for iOS and Android | ×1 | Patient app for iOS and Android | Senior | |
| Backend engineersScheduling, records, billing and APIs | ×2 | Scheduling, records, billing and APIs | Senior | |
| DevOps engineerHosting, backups and monitoring | ×1 | Hosting, backups and monitoring | Senior | |
| QA engineerTest automation and release checks | ×1 | Test automation and release checks | Senior |
03
UI/UX design
Designed for a doctor with a patient in the room.
Who worked on it
The doctor’s screen shows the patient’s history, allergies and last visit at a glance, and notes use templates per specialty. Reception gets a day view of every room, and patients book in three steps in the app.
- Allergies always visibleShown before any prescription is written.
- Templates per specialtyDental, dermatology, paediatrics and more.
- Three-step bookingSpecialty, doctor, time.
04
Frontend
Reception, doctors and billing in one web app.
Who worked on it
Each role sees only its own screens. Reception checks patients in and collects payments, doctors see their queue and write the visit, and billing prepares insurance claims with every required field checked before submission.
- Role-based screensLess clutter, fewer mistakes.
- Claim checksMissing data caught before submission.
- Live queueDoctors see who has arrived.
05
Mobile
Book, pay and see results from a phone.
Who worked on it
Patients book and reschedule, pay online, receive reminders, and view prescriptions and lab results released by their doctor. Family members can be managed from one account.
- Family accountsBook for children and parents.
- RemindersA day before and on the morning of the visit.
- Results on releaseShown only after the doctor approves.
06
Backend & architecture
One record per patient, across every branch.
Who worked on it
A single API serves the web app and the patient app. Scheduling prevents double bookings at the database level, every change to a medical record is kept, and insurance claims are generated from visit data rather than typed again.
Decision 1
Slots reserved in a single transaction
Two receptionists can’t book the same slot.
Trade-off · Bookings wait briefly when a slot is contested.
Decision 2
Medical records are append-only
Every change must be traceable to a person and a time.
Trade-off · Corrections appear as new entries.
Decision 3
Claims built from visit data
Typing the same data twice is where errors start.
Trade-off · Doctors code diagnoses during the visit.
07
DevOps
Health data, backed up and watched.
Who worked on it
Data is encrypted at rest and in transit, backed up daily to a second region, and restores are rehearsed. Access to production is logged, and alerts reach the on-call engineer before reception notices a problem.
- Daily backupsRestores rehearsed, not assumed.
- Access logsEvery production access recorded.
- One release pipelineWeb, API and app shipped the same way.
08
QA
Tested on the busiest morning of the week.
Who worked on it
Automated tests cover booking, check-in, prescriptions and claims, and a load test replays a peak morning before each release. The patient app is tested on real phones in Arabic and English.
- Booking race testsTwo bookings, one slot, every release.
- Peak-morning loadReplayed before each release.
- Real devicesOld and new phones, both languages.
Tell us what you’re building.
A short message is enough. A senior engineer replies within 1 working day.