Wooble
Closed · Closed 25 Jun 2026
Build a live clinic queue system. Replace paper tokens with real-time digital waiting.
Evaluation only · Closed
backend developer · Backend Development - Express.js · Database - MongoDB · database management · Django · ExpressJS
Participation certificate
Get a verifiable certificate the moment you submit your work.
76% of India's 1.5 million clinics run on paper token slips and shouting. Patients wait 2–3 hours with zero visibility. Doctors have no dashboard. Receptionists manage everything from memory.
You are going to fix this.
Build a live digital queue manager for a neighbourhood clinic — visible to patients on their phone, controlled by the receptionist on one screen.
Answer These Three Things
What To Build Screen 1 — Receptionist view: add patient, call next token, set average consultation time Screen 2 — Patient waiting room view: current token being seen, tokens ahead, estimated wait Live sync — both screens update the moment "call next" is clicked One sentence — the moment in your demo that would make a clinic owner say "I want this"
Declared on 6 Jul 2026.
See what strong submissions look like — then build yours on the next challenge.
The queue management task which was done on pen and paper and sometimes not even considered is automated and taken care very effectively by a management system
Reduced patient uncertainty with real-time queue tracking, AI-powered wait prediction, emergency prioritization, and live clinic communication.
Cut patient wait-time uncertainty to zero with live AI-predicted queue tracking across 3 synced screens
AarogyaQ — Smart Queues for Healthier Waiting A production-grade, real-time healthcare queue management system designed to replace traditional paper-token waiting setups with automated client portals, active sound announcements, and direct spreadsheet log compiles. Key Features 1. Receptionist Admin Dashboard Patient Registration: Add patient details (Name, Age, Mobile) to dynamically allocate unique queue tokens (e.g., AQ-001). Live Queue Table: Dynamic sorting, filtering, and row selection tools. Control Station: Trigger "Call Next Patient" (which auto-completes the serving token) or cancel specific patient slots. Consultation Settings: Modify standard checkup time durations (1–60 mins) to update wait estimates. Analytics Engine: Responsive SVG Area & Bar charts depicting queue wait averages, peak patient times, and completed consultation logs (built without heavy external dependencies to guarantee compatibility with React 19). Excel Export: A simple action trigger to instantly download database records directly to the local Downloads directory. 2. Patient Personal Portal Simulated Google & OTP Logins: Native-looking Google Account Chooser popups and animated Mobile SMS OTP code toasts with countdown counters. Profile Management: Maintain persistent medical records (Blood Group, Medical Conditions, Age, Gender) stored securely in client-side storage. Live Waitlist Tracker: Shows active token ticket, queue position, estimated wait times, and progress bar updates in real-time. Self-Queue Booker: Book waitlist queue tokens directly from mobile/web interfaces. 3. Patient Waiting Room TV Display Midnight Dark Mode: Specially optimized layout for large hospital/waiting room television screens. Serving Banner: Giant fonts displaying the active ticket number and called patient name. Audio Voice Chime: Synthetic sound chimes and automated text-to-speech caller alerts powered by the browser's Web Audio API. Helpline Ticker: Smoothly scrolling bottom ticker listing emergency contacts, clinic lines, and support emails. 4. Backend & Sync Architecture Real-time WebSockets: Socket.IO synchronization ensuring 0ms delay updates across all patient and admin screens. SQL Datastore: Persistent SQLite3 database logic managing patient wait lists and settings. Local Excel Synchronizer: SheetJS compiler that automatically syncs the SQLite database to a local spreadsheet (AarogyaQ_Queue_Data.xlsx) in the project root folder on every database update. Tech Stack Frontend: React (Vite), Vanilla CSS, Lucide React Icons, Socket.IO Client. Backend: Node.js (Express), SQLite3, Socket.IO Server, SheetJS (xlsx).
76% of India's 1.5 million clinics still run on paper token slips. Patients wait two to three hours with zero idea when they'll be called. Receptionists manage queues from memory. Doctors have no dashboard. Wait time estimates do not exist. Walkouts happen. Priority cases get lost. Receptionists burn out from constant questions like "how long more?". The fix isn't another booking app, it's giving every role a live view of the same queue. Started by mapping every person who touches a clinic queue, not just receptionists. Ended up with four roles: receptionist (manages queue), doctor (consults), waiting room (passive viewers), patient (anxious). Each needed a different screen. Built the backend first. Socket.IO with per-clinic mutex for concurrency, Zod for payload validation, in-memory state for sub-millisecond reads, PostgreSQL for history. Documented 34 edge cases up front so they wouldn't surprise me later. Frontend went through three theme iterations. First attempt was too generic SaaS. Second was too templated. Third (cream and green with mono token numbers as the signature) finally felt like a real product. Late additions: doctor screen with auto-saving notes, CSV export, patient access token to prevent URL spoofing Shipped a working production system in under a week: - Four live screens that sync in under 200ms - Wait estimates from rolling 10-visit average with confidence-adjusted margin - Absent patient recovery (mark absent, reinstate to front or back, never auto-skip) - 5-second undo on every queue advance - Role-based PIN auth - Patient access tokens prevent URL tampering between tokens - CSV export of any filtered date range Deployed live on Vercel + Render + Neon. Tested every edge case manually with three browsers open side by side. Three things. One, I'd write the design system before any component. Reworking buttons and cards across four screens after they were built cost a full day. Two, I'd put active queue in Redis from the start. In-memory works for a single server but loses state on restart. Documented this as a known limitation, but a real clinic would need persistence. Three, I'd add SMS notifications. The patient page chimes when they're next, but only if their browser tab is open. A real product needs WhatsApp or SMS so patients can step out without losing their place.
We use cookies to measure traffic and improve our ads. You can accept or decline analytics & advertising cookies. See our Privacy Policy.
