queue-cure 26

India's 1.5 million clinics are stuck in the past — 76% still run on paper token slips and verbal announcements. Patients walk in, get a numbered slip, and then sit in a crowded waiting room with absolutely no idea when they'll be called. They can't step out for tea, can't estimate how long to wait, and have no visibility into the queue at all. The average wait stretches to 2–3 hours, and the entire experience is frustrating and inefficient. On the other side, receptionists manage everything from memory — remembering which token was last called, how many patients are waiting, and who is next — I started by understanding the core problem — patients in Indian clinics have zero visibility into their wait time and receptionists manage everything manually from memory. Once the problem was clear, I broke the solution into two screens: a receptionist dashboard to manage the queue and a patient-facing waiting room to show live updates. I chose React with Vite for the frontend because it's fast to set up and component-based, Express for the backend because it's lightweight and pairs perfectly with Socket.IO, and Socket.IO specifically because polling-based approaches would feel choppy and slow — WebSockets give near-instant sync across all connected clients the moment anything changes on the server. The trickiest design decision was the wait time formula. Instead of hardcoding a fixed The project was successfully built, deployed, and submitted to the Queue Cure '26 hackathon on Wooble within a single day. Starting from an empty folder, the entire full-stack application — receptionist dashboard, patient waiting room, real-time Socket.IO server, and all supporting documentation — was completed end to end without any prior boilerplate or template. On the technical side, the app achieved everything the evaluation criteria demanded. Live queue updates sync across both screens in under 100 milliseconds without any page refresh, directly addressing the 40% weighted criterion. Wai If I were to build this again with more time and experience, the first thing I would change is the state management. Using in-memory state on the server means the entire queue is lost the moment the server restarts, which is a real problem in production. I would replace it with Redis from the start — Redis gives persistence, sub-millisecond read and write speeds, and supports Socket.IO's Redis adapter for scaling across multiple server instances without losing sync between clients. The second thing I would do differently is handle the WebSocket transport more gracefully from day one. I ran in