PetPal
A public beta for coordinating pet care between owners and veterinary professionals through shared, permission-aware records and workflows.
Context
PetPal connects pet owners with clinics and veterinary professionals without treating every record as universally shared. Owners manage pets, reminders, appointments, and personal records; clinic members manage services, availability, visits, prescriptions, vaccines, and follow-up work. Accepted connections and clinic membership determine which data can move between the two sides, while completed clinical work remains reviewable instead of being silently rewritten.
Keep pet care information useful to owners and veterinary professionals while making record ownership, clinic access, appointment state, and follow-up responsibility explicit.
Pet care crosses two different working contexts. Owners need an understandable personal record, while clinics need controlled access to connected clients and clinical workflows. PetPal models that relationship directly instead of relying on frontend-only visibility rules.
- Derive private-resource ownership from the authenticated user rather than accepting a user identity from the client.
- Keep owner, clinic-member, and internal clinical visibility rules enforceable by the backend.
- Prevent conflicting appointments and preserve explicit terminal and expired states.
- Keep completed visit records stable while allowing traceable corrections.
- Preserve uploaded pet and visit media across application deployments.
- Present the public deployment as a beta under active testing rather than verified production use.
My role
The product concept and initial design direction came from my wife. I'm responsible for the current system engineering: architecture, backend and domain work, frontend migration and evolution, SSR/SEO work, deployment, testing, and review.
Contribution boundaries
- Product OriginMy wife originated the product concept and established the initial product and interface direction.
- Engineering ScopeI took over the engineering work; I do not claim the original concept or initial design direction.
- Beta MaturityPetPal is a public testing application under active development, not a finished production service with active end users.
System Architecture
Current Next.js, Django API, persistence, role, media, notification, and deployment boundaries.
Backend And Domain
Owner, clinic, connection, appointment, visit, record, reminder, and notification behavior.
Frontend Evolution
Conversion and evolution of the initial interface direction into the current Next.js owner and veterinary workflows.
Delivery And Operations
SSR/SEO groundwork, containerized environments, persistent media, health checks, and testing workflows.
Collaboration credit
- My wifeOriginated the product concept and created the initial product and interface direction.
Architecture
Owner and veterinary care boundary
08 boundaries · 09 declared relationships
- 01Pet owner applicationClient
- 02Veterinary team applicationClient
- 03Next.js delivery layerService
- 04Django care-workflow APIAPI
- 05Relational care recordsDatastore
- 06Protected pet and visit mediaDatastore
- 07Role-targeted notification logicNotification
- 08Containerized application runtimeInfrastructure
Relationship mapInspect 09 connectionsToggle architecture relationships
- Pet owner applicationRequestNext.js delivery layer
- Veterinary team applicationRequestNext.js delivery layer
- Next.js delivery layerRequestDjango care-workflow API
- Django care-workflow APIPersistenceRelational care records
- Django care-workflow APIPersistenceProtected pet and visit media
- Django care-workflow APINotificationRole-targeted notification logic
- Containerized application runtimeHostingNext.js delivery layer
- Containerized application runtimeHostingDjango care-workflow API
- Containerized application runtimeHostingRelational care records
Engineering decisions
01Keep domain authority in the backend
Toggle decision details
Context
Owner and veterinary screens expose different views of shared pets, appointments, visits, and records.
Selected approach
Derive identity from the authenticated request and enforce role, membership, connection, and object scope in Django querysets and workflow validation.
Rationale
Prevent a frontend route or supplied user identifier from becoming the authority for private care data.
Trade-offs
- Every shared workflow needs explicit owner and clinic context.
- Permission regression tests become part of normal feature work.
02Rebuild the product reference around SSR-capable application boundaries
Toggle decision details
Context
The initial product direction existed as a frontend reference with client-side data assumptions.
Selected approach
Preserve the intended product experience while moving delivery to Next.js and business rules, authentication, permissions, and persistence to Django.
Rationale
Support public discovery and clear routing without leaving private workflow authority in browser code.
Trade-offs
- Migration required screen-by-screen parity and removal of mock data.
- The frontend and API contracts must evolve together.
03Make owner-clinic connections an explicit access boundary
Toggle decision details
Context
Veterinary staff need useful access to connected pets without receiving unrestricted access to every owner's data.
Selected approach
Persist owner-clinic relationships and combine accepted connection state, clinic membership, and record-visibility flags in backend access queries.
Rationale
Make cross-role sharing reviewable and narrower than a global veterinary role.
Trade-offs
- Connection initiation and acceptance need counterparty-aware rules.
- Record types still require their own visibility and mutation policies.
04Preserve completed clinical records through amendments
Toggle decision details
Context
A completed visit should remain trustworthy, but clinical corrections may still be necessary.
Selected approach
Freeze completed clinical fields and append attributed amendments instead of overwriting the original record.
Rationale
Keep the original history visible while allowing corrections to be recorded.
Trade-offs
- Readers must interpret the original record together with later amendments.
- Correction workflows are more explicit than ordinary editing.
Runtime ownership
- 01Containerization
Separate Compose definitions keep development, staging, production, and observability responsibilities explicit.
- 02Hosting
I deploy and maintain the public testing application.
- 03Storage
PostgreSQL persists application state and a mounted media volume preserves uploaded files across rebuilds.
- 04Monitoring
A separate optional logging stack can collect and inspect container output without being required for the application to run.
- 05Scheduled Tasks
Management commands handle appointment expiry and overdue follow-up notifications from persisted state.
Inspect operational detail
- The case study does not claim a production scheduler where repository evidence only establishes the commands.
- 06Deployment
Environment-specific stacks use health checks and isolated persistent state for the public beta and test environments.
Current state
- Current
PetPal is publicly deployed for beta testing and remains under active development.
- Lesson
Completed care records should accept corrections without erasing the history that preceded them.
- Lesson
Migrating a product reference is both a frontend conversion and a reassignment of authority to the backend.
Depth B / Technical inspectionInspect supporting evidence
Domain structure and capability evidence.
Toggle technical inspection
Inspect supporting evidence
Domain structure
- Identity and role-aware accessEmail-based users, owner and veterinary roles, cookie-based authentication, clinic membership, and protected self-scoped resources.
- Pets and owner-managed carePet profiles, alerts, photos, documents, medications, vaccines, reminders, and owner-maintained history.
- Clinics, services, and connectionsClinic profiles, staff membership, services, vaccine catalogues, availability, blocked time, applications, and owner-clinic connections.
- Appointments and calendar stateBooking, service and visit type, scheduling conflicts, proposals, terminal states, expiry, and owner/veterinary calendar views.
- Visits and clinical recordsVisits, medical records, prescriptions, medication tracking, vaccines, documents, internal notes, and append-only amendments.
- Follow-ups and notificationsStructured follow-up requests, owner responses, tasks, overdue checks, and role-targeted in-application notifications.
Capability evidence
- System architectureI designed the current browser, API, persistence, role, media, notification, and deployment boundaries.
- API designI implement role-aware APIs for pets, clinics, connections, appointments, visits, records, reminders, and notifications.
- Frontend deliveryI migrated and evolved the initial interface direction into SSR-capable Next.js owner and veterinary workflows.
- Domain modellingI model owners, clinics, memberships, connections, appointments, visits, records, prescriptions, reminders, and follow-ups as related responsibilities.
- Transactional workflowsI protect appointment transitions, recurring reminders, visit completion, prescription tracking, and follow-up state changes.
- Authentication and authorizationI enforce self-scope, clinic membership, accepted connections, record visibility, and clinical write boundaries in the backend.
- Relational persistenceI persist connected owner, pet, clinic, appointment, visit, record, and notification state in PostgreSQL.
- Deployment and operationsI maintain environment-specific container stacks, health checks, persistent media, and the public testing deployment.
- ObservabilityI define a separate logging and inspection stack for container output without making it a required application dependency.
- Automated testingI maintain backend regression coverage for ownership, clinic access, appointments, visits, records, notifications, and follow-up behavior.