QueueCure: real-time queue manager for multi-doctor clinics

Neighborhood clinics have one front desk and a paper list of doctors working from it. The waiting room is full of patients who can’t tell which doctor’s line is shortest, the desk manually juggles every queue, and “your wait is about 20 minutes” is a guess. I set three targets. A patient should add themselves and get a token in seconds. The patient’s phone and the desk should be in sync with no refresh. Wait times should be computed from how long consultations actually take, per doctor, since a paediatrician and a dermatologist move at very different speeds. Process The server owns the truth: each action writes to MongoDB, then Socket.IO pushes to two rooms - a staff room (full detail, behind login) and a public room scrubbed to token numbers, so patients never see each other's names. Each doctor is an independent queue with its own tokens and a learned wait: the rolling mean of their last five real consults, clamped and seeded. A per-doctor lock serialises desk clicks so two taps can't promote two patients at once. What I changed mid-build: one shared passcode didn't scale to roles, so I moved to accounts (admin/reception/doctor) with a dedicated doctor screen. I also leaned on MongoDB's sort for "call next" until a "running late" defer broke the ordering - promotion now sorts by priority → defer → token in one place. Results Patients self-check-in in 2 taps; walk-ins register in one field in under 10 seconds. The desk and the patient's phone update live over Socket.IO with zero refreshes, across four synced surfaces - patient, doctor, waiting-room board, and dashboard. Each doctor's wait is computed from their last five real consults, so estimates track reality instead of a flat guess. The 3× expansion added patient self-service (leave / running-late / feedback / web-push), role-based staff accounts, and an analytics view - each verified end-to-end in the running app. Reflection I'd put real usability testing in front of the build. I validated behaviour by driving the running app, not with users, so "2 taps" is a design target, not a measured task-success rate - interviews and a small task study would let me state that honestly. I'd add automated tests (there are none yet) around the wait-time math and the concurrency lock, where regressions hide easily. I'd also tighten data exposure - a doctor currently receives the full staff feed and the UI just filters it - and make web-push degrade more gracefully across browsers.