A reference build: we made this ourselves to show how we work. It is not a client engagement, there is no customer to name, and there are no measured outcomes to report - so this page does not pretend to have any.
The scanner is the bottleneck, not the doctor
A reference build: scheduling for a multi-site diagnostic centre where an appointment needs a practitioner, a room and a shared device at once - and a cancellation is backfilled from the waitlist automatically.
- Client
- Reference build
- Sector
- Diagnostic imaging
- Year
- 2026
- Built with
- Next.js, TypeScript, Postgres, Flutter, Viber
The numbers
- 5
- Constraints checked together per appointment: practitioner, specialty, room, device, turnaround
- 1
- Solver called from everywhere, because two validators is how a double booking happens
- 6
- Resources on one board: three practitioners, two rooms, one shared scanner
The problem
The practice software models one calendar per practitioner, which is the wrong model for a diagnostic centre: the constraint is the scanner, shared across sites, with a turnaround window between patients. So the real schedule migrated into spreadsheets and a WhatsApp group, double bookings were caught by reception rather than by software, and a cancelled scan hour was simply lost because nobody had time to phone down a waitlist.
What we did
- 1
One solver, called from everywhere. The constraints - practitioner, specialty, room, device, turnaround - are checked together and in a fixed order, and the same function answers the public booking page, the reception screen and the API. Two validators is how a double booking happens.
- 2
The refusal names the collision. "Both rooms are occupied" and "the ultrasound is still in turnaround" are different problems with different fixes, and a receptionist who is told which one it is does not phone a manager.
- 3
Waitlist backfill runs the moment a slot frees, matching on procedure and specialty rather than on order of arrival alone. This is the feature with the clearest commercial case in the entire build, because an unsold scanner hour cannot be sold later.
- 4
Deliberately left alone: the patient record and the prescribing. Those stayed in the existing practice software, which handles them adequately, and the scheduler reads what it needs rather than becoming a second record system.
Where it got to
The scheduler on the clinic page is this solver, running in your browser with invented names. The refusals you get are the refusals reception gets, worded the same way.
A worked example
The scheduler on the clinic page is this solver. Every refusal names the constraint, because that is what reception can act on:
- Practitioner time booked at the start of the day
- 21%
- Ultrasound at 11:00
- in turnaround
- Ultrasound with Dr Vlachou, 2 slots
- she is with another patient
- Cancel the 09:00
- waitlist refills it
- Slot recovered
- automatically
The refill is where the commercial case sits: an unsold scanner hour cannot be sold later, and nobody has time to phone down a list mid-clinic.