Portal for Strays, Fosters, and Transparent Records

Last updated: Feb 11, 2026

A simple, field-first system of record for dogs + cats: stray monitoring (GPS + photos + alias names), feeding routes, foster/adoption workflows, medical records, microchip tracking + registry updates, volunteer coordination, and one-way publishing to adoption listing registries (Petfinder, Adopt-a-Pet, etc.).

Quick start

Pages beyond this index are access-controlled for privacy. Request access at woof@4leggedit.com.

Overview — scope, assumptions, and “what we’re building”
Workflows — how route work, medical follow-ups, and outcomes happen
Data Model — the objects + relationships that support the workflows
Permissions — privacy/redaction rules (Sensitive-by-default for strays)
Release Checklist — what “done” means for Release 1/2/3

Stray monitoring (no custody) → custody → outcome

Location alias names

Volunteer routes + check-ins

Foster portal (redacted)

Clinic appointments + transport tasks

Release roadmap

Three releases, sequenced to match field reality and reduce risk.

Release 1: routes ops (feeding, vaccines, spay/neuter queue), inventory, donations, tasks, privacy/audit
Release 2: foster + adoption processes (applications, agreements, placements, post-placement tasks)
Release 3: external integrations + volunteer onboarding (microchip registries, listings, onboarding flows)

See acceptance criteria for what ships in each release.

What this is

A shared planning pack that aligns product and operations before any software is built.

Everything here is written to be readable by coordinators, volunteers, and builders.

Use the glossary if terms like “Monitoring” or “Sensitive” aren’t obvious.

Rescue work is operational — not just “records”

Most rescue software assumes there’s always a kennel address, a predictable intake pipeline, and staff on-site. Field rescues don’t work like that.

Field-heavy rescue partners operate where the need is highest and the infrastructure is weakest. The work is powered by volunteers, runs on trust, and succeeds through consistency — especially around feeding routes and follow-up.

The pain: information scattered across tools

When animal context lives in spreadsheets, texts, inboxes, social media DMs, and “whoever remembers,” the rescue pays the cost:

Missed or duplicated medical steps (vaccines, spay/neuter, microchip updates)
Unclear custody and foster history when placements change
Volunteer burnout from hunting for details, not doing the work
Risky location sharing for strays/trap sites
Slow reporting when transparency or compliance questions come up

The goal: a “source of truth” that respects field reality

This portal plan is built around a few non-negotiables:

Monitoring vs custody: track strays even when you don’t have custody yet
Map-first events: sightings with GPS + photos + time, plus optional area/territory
Location alias names: volunteers can refer to places by a shared name (even when GPS is redacted)
Volunteer coordination: routes, tasks, check-ins, and skill-based assignment
Lost dog recovery: feeding stations, trail cameras, humane trapping, and owner coordination
Community aid: outreach visits, supplies delivered, and follow-up tasks for owners in need
Redaction by default: sensitive stray locations and trap notes stay protected

Why “docs first”

Before writing code, we write the workflow truth down — in a place everyone can review. That prevents building a portal that looks nice but fails in the field.

Use these pages to review and refine the plan:

Overview — scope and assumptions
Workflows — how the work actually happens
Data model — the backbone (including many contacts per animal)
Permissions & privacy — what’s redacted and why
Decisions log — capture outcomes of team review

Next step

Review the workflows with the people who actually run routes, coordinate fosters, and handle medical follow-up. The portal should feel like “how we already work” — just clearer, safer, and easier to scale.