Manika Jain
Featured project
Clinic Queue
Most clinics in India still run on paper tokens. Patients have no idea about the waiting times leading to anxiety and constant interruptions for the front desk. In busy outpatient clinics seeing 50–100+ patients daily, this creates bottlenecks, miscommunication, and wasted time for both staff and patients. Process Started by identifying the two core users which are the receptionist who manages the queue and the patient who needs live visibility. Designed the system around a shared server state so both screens always reflect the same truth without polling or manual refresh. First attempted a localStorage based approach using browser storage events for cross tab sync, worked but was limited to a single browser and device. Iterated to a Socket.io architecture where the Express server owns all state and broadcasts updates to every connected client instantly. Final system uses an in memory queue on the server, eliminating database dependency while maintaining full real time sync across any device. Results Both screens sync instantly when "Call Next" is clicked , no refresh needed. Wait times are computed from actual consultation start time, shrinking in real time as the current patient is being seen. The receptionist UI handles all edge cases , empty queue guards, duplicate name support via timestamp IDs, confirm dialogs on destructive actions, and keyboard shortcuts for speed. Successfully deployed with a live public URL accessible from any device, demonstrating cross device real time sync beyond what a localStorage approach could achieve. Reflection If I were building this again with more time, the first thing I'd change is persistence. The current in-memory queue resets every time the server restarts , fine for a demo but a critical failure in a real clinic. I'd connect MongoDB from day one so queue state survives crashes, and patient history accumulates across sessions rather than resetting on every page refresh. I'd add a proper authentication layer. Currently any tab that removes ?waiting from the URL gets full receptionist access. A PIN or login on the receptionist view would be the minimum viable security for a real deployment.