WaitWise , Our Story

Inspiration

We've all been there: you drive to a clinic for something minor, only to find a packed waiting room and a 90-minute wait. But for our teammate's friend, it was anything but minor.

She sprained her ankle and made her way to a health clinic downtown, already in pain, just hoping to be seen. What she didn't know was that she'd be waiting 5 more hours before a doctor could see her. No warning, no estimate, no way to know that coming back later could have saved her an afternoon of sitting in agony.

That story stuck with us. Patients deserve better information before they even walk through the door, especially when they're already hurting.

The Quad Cities area has plenty of clinics, but zero tools to help patients time their visits. We wanted to fix that.

What We Built

WaitWise predicts the optimal 15-minute arrival window for nearby clinics using a combination of live and historical data. Open the app, see clinics ranked by predicted wait, and pick a time that fits your day.

The prediction blends two signals - real-time wait data and historical patterns - so that even when live data is unavailable or outdated, the app can still give a reliable estimate based on how busy a clinic typically is at that time of day.

How We Built It

Frontend: React + Tailwind CSS, designed mobile-first so it works on any phone browser with no installation required.
Backend: Python + Flask handling data ingestion, prediction logic, and the API layer.
Data pipeline: Three sources combined, scraped live wait times from CVS MinuteClinic public listings, historical popularity patterns from Google Popular Times for Quad Cities clinics, and simulated demo data for clinics without public feeds.

Simulated data was generated using realistic time-of-day wait curves and is clearly labeled in the UI. In production, this would be replaced by direct clinic API integrations.

Challenges

Data scarcity was our biggest wall. Most clinics don't expose wait times publicly. We spent significant time scraping what little was available and building a believable simulation layer for the rest one that still reflects real-world demand patterns rather than random noise.

Blending live and historical data required careful tuning. A stale live reading can be worse than no live reading at all, so we built in staleness detection to know when to trust the historical baseline instead.

Time pressure meant we had to make fast decisions about scope. We cut features we wanted (push notifications, user check-ins) to ship something solid and demonstrable within the hackathon window.

What We Learned

Real-world health data is messy, sparse, and inconsistently formatted; cleaning it is most of the work.
A well-designed simulation layer can stand in for missing data without misleading users, as long as it's clearly labeled.
Mobile-first isn't just a layout choice; it changes how you think about every interaction.
Splitting a small team across pitch, design, and backend only works if everyone knows exactly what the others need.

Built at HackAugie, April 2026 — Huzefa, Tepy & Nat