Most rescue tech talks about “records.”
Field rescues live in “routes.”
Not just feeding routes — but routes of information: who saw the dog, where, when, what changed, what’s next, and who owns the next step.
When that context is split across texts, spreadsheets, DMs, and “whoever remembers,” the rescue pays the price in missed medical steps, duplicated work, and volunteer burnout.
So we did something simple before writing code:
We wrote the workflows down — clearly — in one place the team can review.
Introducing Portal Docs 🧭
We created a planning portal at:
https://portal-docs.4leggedit.com
It’s a living blueprint for the rescue portal we’re building — designed around real field work from volunteer-powered, field-heavy rescues.
Why this matters (especially for field-heavy rescues)
A lot of systems assume:
- Every animal has a stable address
- Every intake starts at a facility
- Staff are on-site and consistent
That’s not the reality for volunteer-powered field rescue.
These are the real “must-haves” we’re designing around:
- Stray monitoring even when you don’t have custody yet
- GPS + photos + time-based sightings
- Location “alias names” volunteers already use (even if exact GPS is redacted)
- Feeding routes with check-ins
- Lost dog recovery (feeding stations, trail cameras, humane traps, patient monitoring)
- Foster history and transitions (with start/end dates)
- Privacy rules that protect sensitive locations and trap plans
Docs first = fewer wrong turns
Writing it down first lets the people doing the work say:
- “This matches reality.”
- “This is missing a step.”
- “This is risky to expose to volunteers.”
It prevents us from building something that looks nice but fails in the field.
If you run routes, coordinate fosters, do medical follow-up, or manage volunteers, we’d love your eyes on it.
Start with the overview and workflows, then leave decisions in the log.