Inspiration

Wildlife rehab hotlines get crushed every spring; one hotline went from 177 calls a year to 3,500, and a Pittsburgh centre handling 50–60 intakes a day has had to publicly announce on social media that it's pausing intake for specific species because there's no other way to tell people. One rehabber told us: "I can have 30 messages, and none can be answered simply." A lot of those calls are healthy fawns and fledglings that never needed rescuing in the first place; real emergencies get buried under ones that could've been screened out, if only callers knew who actually had room. That gap, between "there's a directory of rehabbers" and "someone nearby can actually take this animal right now," is what we set out to close.

What it does

The Live Capacity Board is a two-sided, real-time system. On the caller side, a short triage flow (species, situation) filters a map down to only the rehabbers who currently have room for that species; not every rehabber within driving distance, just the ones who can actually help right now. On the rehabber side, a one-tap toggle lets a centre update its status in about 10 seconds ("full for mammals, open for birds"), so the public view stays current instead of relying on a static chart or a one-off social media post.

How we built it

We scoped a 7-day MVP around the two pieces that prove the concept: the triage-to-map flow and the live status toggle. We deliberately skipped building a real account/verification system for rehabbers; for the demo, we faked that layer so we could spend the week on what's actually novel: making a rehabber's status change show up on the caller's map in real time. We used React 19 with TypeScript on top of TanStack Start/Router and Vite for the app itself, styled with Tailwind CSS and Radix UI components (Lucide for icons). The map uses Leaflet to render OpenStreetMap tiles, filtered live to rehabbers who are currently open. Data lives in Supabase Postgres, and status updates go out over Supabase Realtime, with a 5-second polling fallback so a caller's map still updates even if a websocket connection drops. The caller triage flow and the rehabber toggle are built with React Hook Form and validated with Zod, and TanStack Query handles data fetching throughout.

Challenges we ran into

The core challenge was proving the "many-to-many, real-time" nature of the problem in a week; showing a state that's genuinely impossible with a static directory, like a caller hitting a "no one nearby has capacity for raccoons right now" result, then watching it change live as a rehabber toggles their status. We also had to stay disciplined about scope: it was tempting to build out proper rehabber accounts and verification, but that wasn't the risky or interesting part of the idea, so we cut it and faked it instead. Draft: replace with what you actually hit: getting status changes to feel genuinely live rather than delayed by a refresh or polling interval; deciding how much of the "account system" to fake convincingly enough for a demo without it looking hollow to judges; keeping the caller triage short enough that someone in a panic mid-drive would actually finish it.

Accomplishments that we're proud of

We got the full loop working end-to-end: triage question → filtered map → a status a static directory literally cannot represent → a rehabber toggling capacity with the map updating live in front of whoever's watching. We also did the harder, less comfortable work upfront: being honest that AnimalHelpNow already solves the "find a rehabber" half of this problem and making sure everything we built was aimed squarely at the live-capacity gap that's actually unclaimed.

What we learned

The clearest lesson was about the shape of the risk: this isn't really a technical problem; it's an adoption problem. The triage-and-map flow is straightforward to build; the real open question is whether working rehabbers; already slammed during intake season- will actually adopt the 10-second habit of updating their status. It's a more plausible ask than getting random passersby to change their behaviour, since it's literally part of a rehabber's job, but it's still unproven. Draft: replace with what you actually took away: that the real risk here is adoption, not engineering; the triage-and-map flow is straightforward to build in a week, but getting a working rehabber to actually tap a status toggle mid-shift is the harder, unproven part. Also learned it's worth naming a strong existing competitor (AnimalHelpNow) directly in the pitch rather than hoping judges don't find it themselves.

What's next for the Live Capacity Board for Wildlife Rehabbers

The immediate next step is replacing the faked rehabber layer with a real, lightweight verification system; simple enough that a rehab center can sign up and start toggling status the same day. After that, the focus is cold-start: getting a first cluster of rehabbers in one region actually using it during a real intake season, seeing whether the habit sticks, and using that as the proof point before expanding region by region.

Built With

Share this project:

Updates

Submission history