ClinicQ — Real-Time Live Queue Manager for Neighbourhood Clinics

76% of India's 1.5 million neighbourhood clinics run on paper token slips. The user pain is uncertainty, patients wait 2–3 hours with zero visibility, not knowing if their turn is in 5 minutes or 90. The business pain is chaos; anxious patients crowd the reception desk every few minutes asking for their turn, causing receptionists to lose focus. The gap identified was a lack of real-time, zero-install communication between the clinic's reception desk and the patient's smartphone to provide transparent, live wait-time expectations. I started by timing clinic workflows. The constraint is that Receptionists can't slow down; entry must take <10 seconds. I first built a REST polling framework ( clients asking 'any updates?' every 3s). I scrapped it immediately—the 3s lag broke the 'live' promise. I pivoted to Socket.IO WebSockets for <100ms real-time push updates. This architectural decision required moving all live queue state in-memory, using MongoDB only as a background persistence layer. My biggest UX iteration was the wait-time algorithm. It evolved from a fixed 10-minute guess, to manual overrides, and finally to a self-correcting 'rolling average' sampling the last 10 actual consultation durations. The breakthrough was adjusting the estimate based on how much of the current consultation had already elapsed. 1. Performance: Patient entry averages 4s. Server-to-client broadcast latency is consistently <100ms. 2. Adoption: The zero-install QR flow achieved frictionless user onboarding. 3. Usability: The wait-time algorithm successfully self-corrects after 2 consultations. 4. Testing: Viewport overflows identified at 472px were fixed for perfect mobile responsiveness. Next time, I'd build architecture for multi-doctor clinics. I tried it late in the cycle, but the queue routing complexity required a fundamental database redesign, so I shelved it to protect core stability. I attempted to build a multi-doctor feature so one clinic could run parallel queues. However, I tried adding it late in the cycle and quickly realized that routing patients required a fundamental database redesign and completely new WebSocket room logic. I stopped working on it, but next time, I would architect the data models for multi-queue support from day one. Additionally, I would adopt a strict mobile-first CSS approach. Retrofitting responsiveness into a desktop-first design cost valuable debugging hours, starting mobile-first would have prevented overflow bugs.