ClinicQu: Clinic Booking with a Live Queue
A clinic appointment platform: a Flutter app where a patient books and follows their position in the queue, and a Laravel backend the clinic runs from a dashboard.
FlutterLaravel 12ReverbTap Payments
Context
Double booking is the failure mode that destroys trust in an appointments product. Two patients tapping the same slot at the same moment is an ordinary race, and its result is someone arriving at a clinic that has no place for them. A queue with no live update means a patient waiting in a room with no information.
Scope I disclose publicly
- A Flutter patient app: booking, queue tracking, medical profile, and payment.
- A Laravel 12 backend owning hospitals, clinics, doctors, bookings, queue state, and waitlists, with a staff dashboard.
- Double-booking protection in two layers: a row lock inside a database transaction, and a composite unique index on clinic, doctor, and date as the second line of defence.
- Live updates over Laravel Reverb on authorised private channels, dispatched after the transaction commits rather than before it.
- Tap Payments with per-clinic credentials, and inbound webhooks verified by HMAC signature before they are accepted.
Decisions and trade-offs
- Preventing double booking in the database rather than the interface: the constraint that actually protects you is the one no code path in the application can route around.
- Dispatching broadcast events after the transaction commits, so nobody is notified about a booking a rollback is about to undo.
- Isolating each clinic's data by relation and query scoping rather than a database per tenant — simpler to operate and sufficient at this size.
- Per-organisation payment credentials, so each clinic's money reaches it directly instead of passing through one intermediary account.
- The trade-off: application-level isolation means any query written without scoping is a potential leak — a constraint that has to be held by review.
There is no public link for this project. It was never published to a store — the bundle identifier is still the framework default — and the running instance is a staging environment on a private server. I state that rather than presenting it as a live product.
Disclosure: Built and paused since June 2026, neither published nor finished. I publish no figures on clinics or bookings.