Kevin Gandhi

A full-stack-ready clinic queue management system with live sync between receptionist and patient vi

In walk-in clinics, patients face overwhelming anxiety due to "blind waits"—often sitting for 2-3 hours with zero visibility into their actual wait time. Receptionists rely on manual paper logbooks, fielding constant "how much longer?" interruptions that slow down intake. The gap was clear: there was no lightweight, real-time bridge between the clinic's workflow and the patient. We needed a digital queue that provided 100% ETA transparency to patients while reducing the receptionist's token-generation workflow to under 2 seconds. Process I approached this by mapping the physical flow of a clinic. Initially, I built a prototype using local React state to test the UI interactions (receptionist vs. patient views). However, local state completely failed the core requirement: multi-device sync. I then evaluated Firebase, but realized a database was overkill and introduced unnecessary polling. Instead, I pivoted to an event-driven architecture using Node.js and Socket.io. I designed a single source of truth where the server broadcasts deterministic states (queue_updated) to all devices instantly. I mapped out the UI to minimize clicks, and created a dynamic ETA algorithm (position × avgTime) that auto-recalculates when the receptionist adjusts the consultation slider. Results QueueCure successfully digitized a high-friction environment. The receptionist workflow was reduced to exactly 2 taps (Name → Enter), taking <2 seconds to onboard a patient. By broadcasting states via WebSockets, we achieved <50ms sync latency, ensuring 100% real-time ETA accuracy across all patient devices. This effectively eliminates "blind wait" anxiety and stops receptionist interruptions. The split-view Single Page Application proved highly resilient during testing, maintaining accurate state even when multiple devices joined simultaneously. Reflection Currently, the WebSocket server holds the queue state entirely in-memory. If the Node server restarts, the active queue is wiped out—which is catastrophic for a live clinic. Next time, I would integrate Redis to persist the queue state robustly while maintaining the sub-50ms broadcast speed. Additionally, I would add SMS integration (via Twilio) so patients aren't forced to keep the web app open on their screens. This would allow them to leave the clinic entirely and simply receive a text message when they are 2 positions away.