Queue Cure '26 — Real-Time Clinic Token Queue

76% of India's 1.5 million clinics still run queues on paper slips and shouting across the room. Patients sit for 2-3 hours with zero idea when they'll be called. Receptionists track everything from memory, and doctors have no visibility into how the queue is moving. I wanted to fix the literal object causing the chaos — the paper token slip — by replacing it with two screens that talk to each other in real time, not a generic "queue app." Process I decided early what NOT to build — no login, no database, no multi-clinic support — so the actual ask, two screens staying in sync, stayed sharp. I picked Socket.io over Supabase Realtime because this hackathon explicitly asks for a socket event diagram, and I wanted the events to be the architecture, not hidden behind someone else's platform. What didn't work first try: I linked the two screens with React Router inside one browser tab. That reused the same socket connection, so the second screen never got the server's initial data push and just sat empty, even though the first screen already had real patients. Fix: every screen now asks the server for current state the moment it mounts, instead of relying on a one-time push at connection. Results Both screens update the instant "Call Next" is clicked — no refresh, no polling. Wait time isn't hardcoded: it's tokens-ahead times the receptionist's own average-consult-time input, recalculated live. The receptionist screen disables "Call Next" while a request is in flight and "Issue Token" until a name is typed, so accidental double-clicks can't skip a patient or submit empty data. If I had more time, I'd add a printable/QR token slip, a WhatsApp ping when a patient is two tokens away, and basic persistence so the queue survives a server restart instead of resetting. Reflection I'd add a printable or QR token slip so patients don't have to remember their number, plus a WhatsApp ping when someone is two tokens away so they can step outside instead of sitting in the waiting room. I'd also add basic persistence so the queue survives a server restart instead of resetting — fine for a one-week MVP, but the first real gap if this went beyond a demo.