ERly | Devpost

Inspiration

Nobody plans a trip to the ER. When you or someone you care about is hurt or sick, the last thing you want is to guess which hospital to go to, or to show up and discover a four-hour wait when another facility down the road might be half that.

In Canada, emergency departments are under strain, and wait times vary wildly by location, time of day, and how serious your case is. Most people have no way to see where to get care right now or how urgent their situation might be. That gap, between "something's wrong" and "I know where to go and what to expect", is what we wanted to close.

We were inspired by a simple question: what if you could describe your symptoms (or say them out loud), get a quick sense of urgency, and see nearby options with real wait-time information, all before you leave the house? Not to replace a doctor, but to reduce anxiety, avoid the worst waits when possible, and help people feel a little more in control when they need care. That's why we built ERly: right care, right now.

What it does

ERly walks you from "something's wrong" to "I know where to go" in one flow.

Describe your situation. You answer a short questionnaire: category (pain, injury, illness, mental health, other), severity (1–5), duration, and a free-text or voice description of your symptoms. Voice input is powered by ElevenLabs (typed input always works). You can skip the questionnaire and go straight to the map, or refine symptoms later in the search bar.
Get a triage sense. Our AI (Backboard) uses your answers to suggest urgency and the right level of care (pharmacy, clinic, urgent care, ER, or ambulance). You get a plain-language clinical summary. The map then loads nearby facilities that match your severity: higher severity surfaces ERs and hospitals; lower severity surfaces clinics and pharmacies. When you choose a non-ER option that's faster than the nearest ER, we show you how much time you save.
See nearby options on a map. ERly shows hospitals, urgent care, walk-ins, and other facilities near you (or near a location you search). Each result shows estimated wait time when we have data (from live feeds, public aggregators, or provincial benchmarks), plus travel time and total time to care. You can filter by type: ER, urgent, walk-in, telehealth, pharmacy, or specialty. We also list virtual options like Telehealth Ontario and Maple so you can consider care from home.
Pick a place and go. Tap a facility to see details: satellite view, wait-time evidence (with a confidence label), and a "View Evidence" breakdown. Hit "Go" for turn-by-turn directions via Mapbox. Before or during navigation you can submit a pre-arrival notice: we build a short clinical report from your triage and selected facility, you review and submit, and the backend notifies the facility and gives you a patient ID so staff know you're on the way.
Optional sign-in. The app works without an account. You can sign in with Auth0 to keep your flow consistent across devices. Everything is geared toward one goal: right care, right now.

How we built it

We kept one thing in mind the whole time: when you or someone you love is hurt or scared, you need clarity, not clutter. You need to know that the wait time on the screen is real, that the triage isn't a black box, and that one tap can get you going. So we chose every piece of the stack to support that. No long forms, no guessing, no "we'll get back to you."

The frontend is a Next.js app so we could ship fast and run smoothly on Vercel. The map had to feel immediate and trustworthy, so we use Mapbox: real satellite imagery around each facility, turn-by-turn directions when you hit Go, and a single, consistent API for search and routing. We wanted voice for people who can't or don't want to type, so we added ElevenLabs for speech-to-text and kept the backend as a secure proxy so the API key never touches the browser. The questionnaire and triage results live in glass-style panels that slide in without hiding the map, because we didn't want users to lose their sense of place. Auth0 is optional; you can use ERly without signing in, but if you do sign in, your flow stays consistent across devices.

The backend is FastAPI on Python. We run it on Render so it's always on and we can point the frontend at one URL. The database is SQLite locally and Postgres in production, with the same schema: care locations, triage sessions, wait-time snapshots, and the evidence we use to show confidence. Wait times were the hardest design choice. We didn't want to show a number we couldn't stand behind, so we built a small evidence pipeline: when we have an official hospital feed or a public aggregator, we use it and tag it with a confidence level; when we don't, we can fall back to provincial benchmarks or a conservative proxy, and we always show the user whether the number is high confidence or estimated. That way nobody is misled. Triage is powered by Backboard: we send category, severity, duration, and the user's own words, and we get back a priority, a recommended care level, and a short clinical summary we can show in the panel and fold into the pre-arrival report. When the user chooses a facility and submits that report, we POST to an incoming-patient endpoint so the facility (in a real deployment) could be notified; for the hack we return a patient ID and a success message so the flow is end-to-end.

Putting it together, we focused on one path: describe your situation, get a clear triage, see options with honest wait and travel times, pick a place, and go. We added filters so you can narrow by ER, urgent care, walk-in, telehealth, or pharmacy, and we surfaced virtual options like Telehealth Ontario so "right care" can mean "from your couch" when that's appropriate. The emotional throughline was simple: we wanted to build the app we'd want in the passenger seat when it's not our day. Right care, right now.

Challenges we ran into

Voice decided to go on vacation. We were so proud of the mic button. Then one of us tried it from campus Wi‑Fi and got "Unusual activity detected" from ElevenLabs. Turns out their free tier can block shared IPs and VPNs. We spent an hour thinking we'd broken something before we read the fine print. So we did two things: we added a friendly error message that tells you to just type your symptoms instead, and we made sure the whole app works great without voice. Now when the mic misbehaves, it feels like a gentle nudge, not a dead end. Lesson: never let one feature be a single point of failure, especially when someone might be in pain.

The frontend and backend refused to talk. Deploy went smooth until we opened the live app and every API call failed. CORS. The browser was blocking our requests because the frontend was on Vercel and the backend on Render, and we'd forgotten to set FRONTEND_ORIGIN on the backend. One env var later and we felt like we'd just fixed the space shuttle with a sticky note. We also learned that Render can take a few seconds to wake up from a cold start, so we added a longer fetch timeout and crossed our fingers. Now we double-check the CORS checklist before we celebrate a deploy.

Wait times are chaos in the wild. Real hospital wait data is gold, but it's not everywhere and it's not always in the same shape. We didn't want to show a number that looked official when we'd basically guessed. So we built a confidence ladder: if we have an official feed, we say so; if we're using a benchmark or a proxy, we label it. That meant more code and more "what if we have no data?" paths, but we sleep better knowing we're not pretending. And we had to accept that sometimes the best we can show is "we don't have a number for this one right now," and that's okay. Honesty over fake precision.

The questionnaire had an identity crisis. We needed enough from the user for triage to be useful, but the moment the form felt like homework, we'd lose them. We kept cutting fields, moving the skip button higher, and making the symptom box the hero. In the end we made the questionnaire optional in spirit: you can skip to the map and still get care options; you can type one sentence and go. The AI does its best with what you give. That balance, between "we need this" and "we're not your doctor's office," was a lot of back and forth. Worth it. Nobody wants to fill out a form when they're scared.

Accomplishments that we're proud of

The best one: hearing our loved ones, people around us, and sponsors and organisers say they would actually use it. Not "nice demo," but "I'd use this next time I don't know where to go." That hit different. It reminded us we weren't just building for a scoreboard; we were building something that could sit in someone's pocket on a bad day.

We're proud of shipping a full loop: describe your situation, get triage, see real care options with wait and travel time, pick a place, get directions, and send a pre-arrival notice with a patient ID. No hand-wavy "we would connect to hospitals"; the flow is there, and it works. We're proud of being honest about wait-time data instead of faking confidence, and of making voice a nice-to-have instead of a single point of failure so the app never leaves you stuck. We got the frontend on Vercel and the backend on Render, CORS and cold starts and all, and it's live. And we're proud of the small details: the "time saved vs nearest ER" message when you choose a smarter option, the telehealth list so "right care" can mean calling 8-1-1 from your couch, and the optional questionnaire so you can skip the form and still get help. Right care, right now. We built it, and we're proud that the people we care about said they'd use it.

What we learned

Resilience beats flash. When voice broke on campus Wi-Fi, we learned that the best feature is the one that still works. We made typing first-class and turned voice into a bonus. For healthcare especially, we don't get to say "try again later." So we design for fallbacks and clear messages, not for the happy path only.

One missing env var can feel like the whole app is broken. CORS taught us that production is a different planet. We now treat deploy checklists and env vars (like FRONTEND_ORIGIN and timeouts for cold starts) as part of the product. Boring, but it's what makes "it works on my machine" become "it works for everyone."

Honesty is a feature. We could have shown a fake wait time everywhere and called it a day. We learned that labelling where our numbers come from (official feed vs benchmark vs "we don't have data") builds trust. Users can handle "we're not sure" if we say it. They can't handle numbers that look real but aren't. That mindset will stick with us.

Short and optional wins. The questionnaire taught us that in a stressed state, people bounce fast. We learned to ask for the minimum, make skip obvious, and still deliver value. "Optional in spirit" became our guide: give the AI something to work with, but never make the human feel like they're filling out a form for us. We're not the ER front desk; we're the thing that gets you there.

Building something people would use changes why you build. When loved ones and organisers said they'd use ERly, we stopped thinking of it as a demo and started thinking of it as something that could be in someone's pocket on a bad night. We learned that the best validation isn't a score; it's someone saying "I'd use this." We're taking that into whatever we build next.

What's next for ERly

We'd love to turn the pre-arrival notice into a real handoff. Right now we POST to our backend and return a patient ID; next step is partnering with one or two facilities so that notice actually lands on a dashboard or queue. Staff would see who's coming, with what, and in how many minutes. That's the dream: close the loop between "I'm on my way" and "we're ready for you."

We want more and better wait-time data. More official hospital feeds, more provinces, and clearer "last updated" so users know how fresh the number is. We'd also explore simple predictions (e.g. "usually quieter after 10 p.m.") where we have enough history, always labelled so people know it's an estimate. And we'd love to go beyond Ontario: same flow, more regions, so "right care, right now" can matter in more time zones and more cities.

On the product side: a proper mobile experience (or PWA) so ERly feels native on a phone when someone's already stressed, better accessibility (screen readers, clearer contrast, maybe more languages), and small quality-of-life wins like "notify me when wait times drop" or "best time to go today." We'd also dig deeper into the triage summary so the pre-arrival report is even more useful for the care team. We're not done. Right care, right now is the goal; we're just getting started.

Further inspiration: Vivirion Solutions

We were inspired by Vivirion Solutions and what they’re building for healthcare professionals and families. We see ERly as a natural complement to their ecosystem, not a pivot. On the patient flow side: when people show up at the wrong place or with the wrong expectations, the staff Vivirion trains spend time on triage and redirect instead of delivery of care. ERly gets patients to the right level of care (clinic, urgent care, ER) before they leave, with triage and wait-time data. Fewer mismatched arrivals means the professionals Vivirion empowers can do the work they were trained for. On the workflow side: our pre-arrival notice and clinical summary give facilities a heads-up: who's coming, with what, and in how long. That's a practical tool that fits right into the "prepare the front line" idea. And on the navigation side: if Vivirion has or plans on extending ViNav on "where do I go?", ERly adds symptom-based triage, real wait and travel time, and turn-by-turn directions so both patients and the workers Vivirion supports benefit from smarter routing. Same goal, different angle: better care for everyone.