From a dashboard to an experience.
A growing product stage, composed interfaces and purposeful interactions explain the daily workflow. Motion introduces the product; it does not take control of scrolling.
← Projects
Product Engineering · Veterinary Operations · Kenya
PawSuite
Run the clinic. Work the field. Keep one record. I’m building the product, its secure foundations and an interactive experience that makes connected veterinary care feel tangible.
From clinic desk to farm gate
One practice.
A world of care.
I’m building PawSuite around the work between appointments: the handover, the field note, the stock movement and the follow-up. The public experience makes that connected story tangible.
Step inside the experience
Experience the product
The workflow is the story.
Four moments from the redesigned PawSuite experience. Explore the interfaces, then see the product decision behind each one.
THURSDAY · THE MORNING LINE-UP
A busy day. A clear picture.
12 Appointments03 In the clinic02 Field visits
NalaWellness visit · Dr AminaIn consultation
MiloFollow-up · Dr AminaExpected
Karura DairyHerd visit · Dr DavidField team
THE DESIGN DECISION / 01
Make the handover visible.
A shared queue makes ownership and the next action legible. The interactive check-in demonstrates the change rather than asking a visitor to imagine it.
where it belongs.
CLINICAL RECORD · NALAOne patient.
One patient.
One connected story.
Golden retriever · Female · 3 years
Weight24.8 kgTemperature38.5 °CLife stageAdult
S
SubjectiveRoutine wellness visit. Eating and activity unchanged.
O
ObjectiveObservations stay attached to this visit.
Open the care plan
Document examination findings and agree the next check-up with the owner. This demonstration preserves the distinction between a draft and clinical sign-off.
THE DESIGN DECISION / 02
Keep the person close to the patient.
Photography anchors the clinical UI in care. History, observations and the next step sit together, with progressive disclosure for the care plan.
Your notes shouldn’t.
09:41 •••
FIELD VISITKarura Dairy
Working offlineMilking herd
24 cattle · Farm block A
VISIT NOTES
Herd observations recorded. Review individual animal findings with the clinic team.
Saved on this deviceWaiting for a connection
THE DESIGN DECISION / 03
Treat connectivity as part of the workflow.
The reconnection interaction changes the draft’s state without pretending it has become final. Useful offline work and authoritative review remain separate.
ATTRACT & RETAIN CLIENTSA first visit.
A first visit.
A lasting relationship.
The client journey belongs in the product story too. Booking, clear updates and useful reminders connect the clinic visit to the care that follows at home.
- Make booking easier
- Keep care information close
- Continue the conversation
- Bring the next check-up into view
HELLO, AMINA
A little care for Nala.
UPCOMING VISIT
Wellness check-up
Thursday · 09:00
Appointment details ↗VisitsCare updatesMessages
THE DESIGN DECISION / 04
Connect product value to the relationship.
A pet-owner view turns a feature list into a familiar moment: the upcoming visit, the reminder and the conversation that continues after the appointment.
Interactive product demonstrations · application delivery is documented below.
Designing the first impression
Make the product understandable before the first login.
One platform. Different practice days.
Clinic photography, field imagery and the illustrated care world help companion, mixed and mobile teams recognise their own work.
Clarity is part of the craft.
Readable text, stronger contrast, keyboard-operable tabs, reduced-motion support and progressively revealed features keep the experience approachable.
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
A secure foundation. A richer product experience.
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.
DeliveredInteractive public experienceImmersive product chapters, illustrated practice explorer, business-type stories, a visual feature directory and client-relationship storytelling.
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.