Clinic Queue Manager — live token system

Clinic Queue Manager — Problem Statement The problem no one talks about, but every patient feels Walk into any government hospital, urban clinic, or small-town diagnostic centre in India. The first thing you encounter is not a doctor — it is a crowd. A shapeless, anxious, uninformed crowd. People clutching paper slips, asking strangers "who came last?", standing for hours with no idea whether they are third in line or thirtieth. This is not a rare edge case. It is the daily reality for millions of outpatients across the country Process My process — Clinic Queue Manager How I read the problem before writing a line of logic The brief gave me three questions and a build spec. Most people jump to the build. I did not. I spent the first few minutes mapping what the three questions were actually testing — because they were not random. They were testing whether I understood the failure modes of a queue system, not just its happy path. Question 1 — speed of input — is really asking: will receptionists actually use this, or will they find a workaround? If adding a patient takes 20 seconds, a busy front desk will go back to paper in three days. Question 2 — live updates without refresh — is really asking: do you know what WebSockets are for, and do you understand that a patient who has to press F5 to check their Results Speed— A receptionist can add a patient and assign a token in under 10 seconds. Two fields, one click. Tested in the live demo repeatedly without breaking that threshold. Accuracy— Wait time is never hardcoded. From the second "Call next" event onward, the system computes a rolling average from actual inter-call timestamps. By mid-session, the estimate is self-correcting — if the doctor runs fast, every patient's displayed wait time drops automatically. Zero-lag sync — Both screens update in the same render cycle the moment an action is taken. Reflection I answered the failure before the feature Most submissions build the happy path and stop. I started by asking what breaks each requirement in the real world — a receptionist who abandons a slow tool for paper, a patient who stops trusting a screen that needs refreshing, an estimate that lies by 11 AM. Every build decision came from those failure modes, not from the feature list. I made the proof visible in one moment Instead of describing the live sync, I put both screens side by side in the same view so a judge can see the patient panel update