Independent project · Design + full-stack engineering
VetNest.Veterinary website development,
with the workflows behind it.
I designed a warm front door for pet parents and built a permission-aware workspace for the team—one connected platform, from the first impression to the last database write.
Explore the build- Role
- Product design · Full-stack
- Platform
- React · TanStack · Cloudflare
- Foundation
- Xonava · D1 · R2
- Project type
- Independent software demo
Designed and built by Suriyaprakash Somu
Fig. 01 — Actual development build · Sample data · Stock care photography
§ 01 — The brief+
Not another brochure site.
The public website and the staff workflow should not feel like two unrelated products.
I brought product design, content publishing and full-stack engineering together in one independent build.
I started with two connected needs: help pet parents understand the available care, and give the clinic a practical way to keep that information current. I designed the public experience around clear service discovery, useful content and approachable visual language.
I then built the publishing tools and operational workflows behind that experience: structured service and team content, connected customer and pet records, and a staff workspace with explicit permission boundaries. I wanted the public website and the dashboard to work as parts of the same product.
I handled the information architecture, visual interface, reusable admin components, server-side authorization, persistence and test coverage. I focused on connected workflows with clear rules for ownership, publication and change, giving each feature a consistent place in the wider system.
Discover
What care is available, who provides it and how to make contact.
Publish
Keep service details, staff biographies and clinic information current.
Operate
Connect customers, pets and appointments without blurring access.
§ 02 — The experience+
Three audiences. One system.
01 / For pet parents
Understand the care before making contact.
I designed the public journey to help a pet parent understand the care before making contact. I use approachable language, clear service discovery and practical visit information, then separate short introductions from full descriptions, durations and current prices. I gave team profiles room for biographies and professional information so the people behind the care have a meaningful presence. Every page supports the next step without asking visitors to understand the clinic’s internal structure.
Public website → service detail → clinic enquiry
02 / For the clinic team
Publish once. Keep the story consistent.
I built publishing workflows for services, product categories, banners and staff profiles. I combine structured fields with rich-text descriptions and owned photo galleries, and I make publication an explicit decision. I also connect public staff visibility to the linked account’s active state. I keep clinic identity and opening hours separate from private configuration, giving editors a focused way to maintain public information while preserving a clear data boundary.
Draft content → review details → explicit publication
03 / For daily operations
Connect the records behind the visit.
I connected customers, pets, services and staff-assigned appointments in the dashboard. I derive appointment duration from the selected service and check staff schedules when a booking is created or changed. I built a separate customer portal for the customer’s own profile and active pet records, with its own authentication boundary. That gives me one connected data model with deliberately different experiences for the people using it.
Customer → pet → service → staff appointment
Record relationships / simplified
- 01
Customer
Owns the relationship
- 02
Pet
Belongs to that customer
- 03
Service
Defines the visit duration
- 04
Staff appointment
Checks schedule availability
A conceptual data-flow illustration, not a patient record or a self-service booking screen.
§ 03 — Architecture+
The interface is only the beginning.
Experience layer
React / TanStack Start
I built server-rendered public routes, rich content and a reusable administrative interface, with clear states and actions across the experience.
Decision layer
Xonava / session-derived identity
I use Xonava for verified action scopes, row and field authorization, validation, idempotency and optimistic concurrency, with application rules joined at the framework boundary.
Persistence layer
Cloudflare D1 / R2
I use relational records and explicit media references, commit correctness-critical effects together, and connect public file visibility to content ownership.
My architectural approach
I use the framework’s supported guarantees across modules and keep application business rules explicit. That gives me a consistent foundation for permissions, writes and extension without creating a different correctness model for every feature.
§ 04 — Decisions & trade-offs+
The details that make it hold.
01 / Not just a hidden button.
Authorization belongs on the server.
I derive identity from server-side sessions and use Xonava’s attribute-based access control for module admission, row scope and field projection. I keep supporting dropdown reads narrow and module-owned. That lets me make permissions consistent across lists, details and mutations, while using the interface to communicate the actions available to each person.
A consistent permission boundary across lists, details and writes.
02 / Correctness before convenience.
A write is more than an UPDATE.
I use the framework’s write lifecycle to connect version checks, before-and-after authorization, idempotency, audit events and cache invalidation. I add application rules such as staff scheduling and media ownership at that boundary, keeping correctness-critical effects together. I chose this approach to make the consistency rules explicit and reusable across feature modules.
Optimistic concurrency and atomic write-side effects, not last-write-wins editing.
03 / Uploading is not publishing.
Published media needs an owner.
I attach photos to their parent records with explicit references and make fresh public serving follow the owner’s visibility. I use a separate aggregate for public staff presentation, keeping login data out of the profile model. I also account for the documented cache lifetime when designing publication changes, so the ownership and delivery rules remain clear.
A reviewed relationship between file storage, content ownership and visibility.
04 / More than a one-line description.
Useful content needs structure.
I use short summaries for cards and introductions, and full rich-text documents for biographies, preparation guidance and catalogue details. I align validation with the renderer’s supported content model. I populated the demo with substantial descriptions in those actual fields so I could exercise long pages, editorial states and the content experience as a whole.
Twenty-nine distinct seeded detail pages across staff, categories and offerings.
§ 05 — Engineering quality+
Built carefully. Tested deliberately.
How I validate the build
- I exercise write consistency and rollback using real SQLite behind a D1-compatible adapter.
- I test scoped reads, field projection, revoked access and shared-record version conflicts.
- I validate rich documents, public rendering and ownership-aware gallery paths.
- I use connected demo fixtures with complete descriptions and tests that preserve edits on rerun.
How I keep the system coherent
I carry the same rules through the form, API and database. A permission-aware interface is backed by server-side checks; versioned edits use optimistic concurrency; and correctness-critical side effects stay in the supported atomic write boundary.
I make those decisions visible in the structure of the code and the regression tests. That keeps the foundation understandable as I add modules, refine workflows and adapt the platform to a different clinic’s requirements.
One connected experience. Consistent rules underneath it.
§ 06 — Custom implementation+
A foundation for your next build.
I build for clinics that need a distinctive website, structured service and team publishing, and connected staff or customer workflows. I shape the identity and content around your practice and the permissions around how your team actually works.
I start by understanding your existing tools, who maintains content, what data needs to move and which actions need review. Then I define the implementation with you and build the workflows that support it.
Talk through your requirements- 01
Discover
I map your clinic’s audience, existing tools, content ownership and operational needs. I connect what the public needs to understand with what your team needs to manage.
- 02
Adapt
I shape the visual identity, service hierarchy, content model and permissions around that brief, adapting existing foundations and designing new workflows where needed.
- 03
Validate
I review content and access rules, test the agreed workflows and configure the delivery environment. I plan data import, recovery and acceptance checks alongside the build.
- 04
Launch & improve
I release against the agreed acceptance checks, then use enquiries, content feedback and field performance to guide the next improvements.
§ 07 — Before you ask
A few useful
distinctions.
Is VetNest a real veterinary clinic?
I built VetNest as an independent software project. The demo uses a fictional clinic and sample records to make the connected workflows easy to explore. Care photographs illustrate the interface rather than identifying the named demo staff.
Can this become a website for my veterinary practice?
Yes. I can adapt the branding, content structure, service catalogue, team publishing and operational workflows around your practice. I start with your requirements, then agree the implementation, integrations, hosting and support that suit the project.
How did I build the appointment workflow?
I built staff-managed appointments connected to customers, pets, services and staff schedules. I derive the visit length from the service and validate the booking relationships. Public pages provide service information and enquiry paths, while the staff team manages appointment creation.
What did I bring together in VetNest?
I connected a public veterinary website with service and team publishing, customer and pet records, a separate customer portal and staff-managed appointments. I use a permission-aware foundation so those related workflows can serve different people through clear access boundaries.
Why is the demo excluded from search results?
I keep the product story discoverable here and use noindex for the fictional clinic demo. For a real clinic implementation, I configure its own indexing policy, verified business details, canonical origin and search setup around the actual practice.
Can I see the application or discuss a project?
Yes—email me for a walkthrough. Tell me about your clinic, the workflows you want to improve and the systems you already use. I can show you how the application fits together and discuss how I would approach your implementation.