Wooble
Hazel Sequeira

Hazel Sequeira

Full-Stack Developer

Fr. Conceicao Rodrigues College of Engineeringfull_time, internship
1Projects
6Skills
1Achievements
Open to roles
Hazel Sequeira

Hazel Sequeira

Featured project

Clinicque - Live Queue Manager for Neighbourhood Clinics

76% of India's 1.5 million clinics run on paper token slips and verbal announcements. Patients wait 2–3 hours with no idea where they are in the queue. Receptionists manage the entire flow from memory where there is no dashboard, no history, no way to communicate delays. The moment a patient steps outside or loses track of the number being called, they miss their turn. The problem isn't that clinics lack technology. It's that the only tool that exists , the paper slip breaks the moment the patient walks away from the front desk. Process I started from the brief's three questions and worked backwards. Instead of designing screens first, I mapped the state machine first because in a queue system, every UI decision follows from what states a token can be in and what transitions are legal. That gave me a clear contract before I wrote a single component. I chose Firebase Realtime Database over a polling approach deliberately: polling introduces a lag window where one screen is ahead of another, which breaks the clinic owner's core trust in the system. The architecture had to be push-first from day one, not retrofitted later. Results The receptionist flow was timed at roughly 12 seconds on a real device with name entry, token auto-assigned, patient added to the live queue. A first-time user picked up the receptionist view without any walkthrough, which was the more useful signal: the interface communicates its own affordances. The patient screen and display board updated the moment "call next" was clicked, with no action needed on the patient's end. Reflection Start with Firebase security rules, not add them at the end The current DB is open for demo purposes. A production deployment needs per-role write rules — receptionists can write to the queue, patients are read-only, display is read-only. Designing those rules early would have shaped the data model, not forced a retrofit. Test the wait estimate algorithm with a longer session The rolling average works well once 4–5 tokens have completed. In the first two tokens of a session it leans heavily on the configured default. I'd add a confidence indicator — something that tells the patient "estimat

4 media files · clinque.netlify.app
<10s <10s receptionist adds patient + assign0 refreshes patient view updates live via Firebase3 roles receptionist · doctor · patient
View project

Proof of work

2 skills backed by real projects on this profile.

Core skills

ML EngineerProject ManagementGITJavaPythonWeb Development

This is Hazel’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours