Yash Munshi

MediQueue

76% of India's ~1.5M clinics still run on paper token slips and shouted names. Patients take a paper number and wait 2–3 hours with zero visibility into when they'll be seen. So they can't step away, and waiting rooms stay crowded. Receptionists track the entire queue from memory; doctors have no view of who's next. The gap: no affordable, real-time system that shows patients their live position and lets one receptionist run the day from a single screen across multiple doctors and rooms. Process I started from the real problem, paper tokens in Indian clinics, and mapped the three people involved: receptionist, patient, doctor. My first version let patients self-join a queue, but that broke the real-world flow (reception controls who's in line), so I rebuilt it as reception-driven... [load-testing surfaced race conditions → WAL + atomic transactions; reworked wait-time math twice]. Results Real-time queues sync across the clinic dashboard, patient phone, and waiting-room display from a single broadcast. Concurrency held: 25/25 simultaneous Call-Next / Add-patient operations produced unique, non-double-served tokens (0 race conditions). Patients get a live token countdown plus an email when the person ahead is called, cutting dead time at the clinic. The platform also ships multi-room serving, departments, priority tokens, no-show recall, a live-queues explore map, clinic verification, 3 languages, and dark mode — deployed on Render + Vercel. Next: a real clinic pilot to measure Reflection I'd validate with a real clinic before building features. My wait-time figures (2–3hr → <1hr) are design targets from the problem statement, not measured outcomes — I'd run a pilot and instrument real wait times. I'd add automated tests earlier (I load-tested concurrency by hand) and split the backend sooner, as it grew into one large file. On the frontend I'd lazy-load the map and design mobile-first from the start, instead of adapting the desktop layout afterward.