Problem
Booking a doctor in Nepal often means phone calls and queues, with no clear view of who is available or when.
Approach
A versioned REST API (/api/v1) serves a Flutter app. It covers patients, doctors, specializations, schedules, appointments, payments, reviews and messages, with Sanctum authentication and role-based access for patients, doctors and admins.
Available slots are generated from each doctor’s schedule when requested. An appointment moves through clear states (pending, booked, completed, missed) and is tied to its payment. A Filament admin panel handles operations and reporting.
Swipe sideways to see the whole diagram.
Key decisions
-
Slots calculated from schedules on request, not stored
- Why
- They can never go stale when a doctor changes their schedule.
- Trade-off
- Slots are computed on every lookup.
-
An explicit appointment lifecycle tied to payment status
- Why
- Paid or booked appointments cannot be changed by accident.
- Trade-off
- More states for the app to handle.
-
A versioned API from the start (/api/v1)
- Why
- The mobile app keeps working while the API evolves.
- Trade-off
- Older versions have to be kept alive until every app has updated.
-
Filament for the admin panel
- Why
- A complete admin with charts and tables without building one from scratch.
- Trade-off
- Tied to Filament's conventions.
Result
A working mobile app and API covering the whole flow, from finding a doctor to booking, paying and leaving a review.