Today’s practice
One operational view for queue pressure, field work, follow-up, payment attention, and stock signals.
Queue→Work→Follow-up
← Selected work
Product Engineering · Veterinary Operations · Kenya
PawSuite
A Kenya-first veterinary practice-management platform designed for clinic, mobile, mixed-practice, and field teams — with workflows, trust boundaries, payments, offline behavior, and operational state treated as one connected product system.
Product promise
Run the clinic. Work the field. Keep one record.
The product is designed as an operational backbone rather than a collection of disconnected veterinary screens.
- Clinicqueue · visit · dispense · checkout
- Fieldassigned work · local draft · reconnect review
- Controlinventory · payments · audit · permissions
Operating model
Build the workflow, not the menu.
PawSuite is deliberately delivered through complete veterinary work loops. Database entities such as clients, appointments, invoices, and inventory matter, but they are useful only when the handoffs between reception, clinical work, field work, checkout, and follow-up make sense together.
Three product stories
One calm operational workspace.
These are the three experience stories that guide the product and public mockups: today’s practice, the clinic visit, and the field draft.
Clinic visit
Preserve context from intake through consultation, clinical documentation, prescription, checkout, and the next action.
Intake→Visit→Checkout
Field draft
Weak connectivity is represented honestly: local work can be recovered, synchronized, reviewed, and only then finalized.
Local save→Sync→Review
Product state
Offline is a state model, not a connectivity badge.
Field workflows need to explain what is local, what is stale, what is waiting for the server, and what is authoritative. PawSuite uses explicit state language so a user is never encouraged to confuse a recoverable draft with a final clinical or financial action.
Honest system states
The same vocabulary is intended to appear across product UI, offline behavior, and public mockups.
DraftEditable work that is not final.
Saved on this deviceLocal recovery exists; the server may not have it.
Stale cached dataSafe for context, but the source may have changed.
Pending syncWaiting to reach the server without duplicating final actions.
Needs reviewA conflict or rejection preserves the work and requires a choice.
Final / verifiedAuthoritative state with explicit correction or reversal paths.
Architecture
Local operating realities shape the system design.
PawSuite is Kenya-first without making the architecture Kenya-only. The product favors a modular monolith and explicit domain boundaries, with integration seams for payments, messaging, interoperability, and eventual cloud deployment.
Key engineering decisions
Each decision connects product behavior to a technical boundary.
Mixed practices from day one
The animal, visit, forms, inventory, and field models cannot assume a dog-and-cat-only clinic. Individual animals and groups/herds are both part of the product thesis.
Daraja first, provider-agnostic ledger
M-PESA is a Kenya-specific implementation priority, but invoice settlement stays separate from the payment-provider adapter so cash, manual references, and future rails remain first-class.
Draft offline, finalize authoritatively
Field notes and observations may be recoverable locally. Clinical signing, payment verification, stock deduction, and permissions remain server-authoritative final actions.
Modular monolith before service sprawl
Next.js, Fastify, PostgreSQL/Drizzle, shared packages, and an outbox/worker boundary keep the early system understandable while preserving clean seams for later scale and integrations.
Standards-ready, not standards-led
Clinical work stays natural for the vet. Mapping layers can later translate internal concepts into FHIR, LOINC, VeNom/SNOMED, CSV, PDFs, or reporting artifacts without forcing those standards into every interaction today.
Google Cloud is the deployment target, not a current claim
The repository records GCP as the deployment direction, with region, cost, and latency validation still part of the delivery decision rather than presenting an undeployed architecture as live.
Current build
The foundation is real; the later clinic loops are still staged.
The implementation sequence intentionally puts tenant isolation, database evidence, sessions, and browser authentication ahead of the broader clinical, payments, inventory, and offline product slices.
Delivery state
This portfolio reflects the repository state rather than the complete future MVP vision.
Implemented
Phase 0 · repository & app foundation
Fastify API, Next.js app shell, shared packages, CI, typed config, tests, and local PostgreSQL tooling.
Implemented
Phase 1 · database foundation
Tenancy primitives, audit/outbox/idempotency foundations, seed data, migrations, and verification tooling.
Verified
Phase 2A · identity & tenancy
Multi-practice memberships, system roles, forced RLS, opaque sessions, tenant bootstrap, audit/security evidence, and native PostgreSQL verification.
Current foundation
Phase 2B · authentication boundary
Atomic password login and refresh transactions plus browser-safe login, refresh, logout, and current-session routes with HttpOnly cookies, strict-origin controls, CSRF binding, and negative tests.
Planned
Next vertical slices
Registry and activation, clinic/field visits, billing and M-PESA, clinical workspace, inventory, messaging, reports, and the bounded offline sync center.
Engineering evidence
Security and correctness are part of the product foundation.
The identity and authentication work is useful portfolio evidence because it shows how the product handles isolation and browser trust before sensitive veterinary and financial records arrive.
Tenant isolation
Forced PostgreSQL RLS, transaction-local tenant/user context, active membership resolution, and tests exercising switched and missing tenant contexts.
Session lifecycle
Opaque-session persistence, refresh rotation/replay handling, expiry behavior, self-revocation, and append-only security evidence.
Atomic authentication
Password verification, credential-race handling, transparent Argon2id rehash, session issuance, refresh rotation, and replay compromise are coordinated through PostgreSQL transactions.
Browser-safe credentials
Access and refresh credentials stay in HttpOnly cookies; session-bound CSRF, exact-origin CORS, SameSite=Strict, no-store responses, and generic authentication failures define the HTTP boundary.
Public claims stay bounded
Mockups can preview accepted workflow concepts, but the portfolio distinguishes implemented identity/auth foundations from future clinical, financial, inventory, and offline vertical slices.
Correct state over optimistic UX
Draft, local save, pending sync, conflict, verified, and final states are intentionally different so the interface does not turn network uncertainty into clinical or financial certainty.
Current boundary
PawSuite is further along as a product system than as a finished clinic application.
That is intentional. The product thesis, workflows, architecture, data model, tenancy, database security, and authentication boundary are being established before the broader operational modules are represented as complete.
Not claimed as complete
- Full client, animal, and herd registry
- Clinic and field visit vertical slices
- Daraja STK and payment reconciliation
- Clinical SOAP workspace and documents
- Inventory, batches, dispensing, and vaccinations
- Full offline synchronization and conflict UI
- Production Google Cloud deployment
Explore PawSuite
The public site shows the product vision; the build is catching up workflow by workflow.
The live experience is useful for the product story and early-access positioning. This case study is deliberately stricter about what has already been implemented in the application foundation.