ClinIQ — Real-Time Clinic Queue Management System

Small clinics in India manage patient queues with paper tokens and manual name-calling. Patients have zero visibility into wait times — they cluster anxiously around doors, miss their turn, or leave frustrated. Receptionists waste time tracking who is next. No data is collected, so clinics cannot improve. The problem affects thousands of small clinics daily, yet no simple, affordable, real-time solution exists for them. Process Started by identifying the core pain: paper tokens + zero patient visibility. Chose Socket.IO over HTTP polling after comparing real-time options — auto-reconnect and polling fallback were critical for clinic networks. Built a REST + Socket.IO hybrid: actions go via REST for reliable error handling, broadcasts go via Socket.IO so every screen updates instantly. Designed dynamic wait-time calculation from actual consultation durations instead of hardcoded estimates — this was the key insight. Handled concurrency at the database level using MongoDB unique indexes and retry loops, not just UI-level disabling. Kept the feature set intentionally minimal: no auth, no payments, no AI — just reliable real-time queue management that a real clinic could deploy tomorrow. Results Both receptionist and patient screens update in under 100ms after any action — no refresh needed. Wait times recalculate dynamically after every completed consultation, becoming more accurate as the day progresses. Duplicate token generation and double-click concurrency issues are fully handled at the database level. The system is stateless, MongoDB-persisted, and deployable on Render + Vercel in under 20 minutes. A receptionist can add a patient to the queue in under 10 seconds with zero mouse usage. Reflection I'd add a lightweight offline mode earlier — many small clinics in India have unreliable internet, and running the backend on a local network would make ClinIQ viable for rural clinics without any changes to the frontend. I'd also build per-doctor queue support from day one, since most clinics have multiple doctors. The schema already has the right fields, but the UI assumes one queue. Finally, I'd conduct at least two real receptionist usability sessions before finalising the dashboard layout — assumptions about "fast workflow" should be validated, not just built.