Engineering case study / 01
Better stays.
Smoother operations.
A pet-boarding operations platform built around real staff workflows, complex reservation rules, and data that needs to stay consistent.
Enter as Receptionist or Manager. Shared fictional data is scheduled to reset daily; no messages or payments are sent. After inactivity, please allow about a minute for the demo to wake up.
01 / THE CONTEXT
Build around the people
doing the work.
The application is intended to replace a similarly functioning legacy system from the 2000s. Its users are reception staff, managers, and administrators at a pet-boarding facility.
I designed and implemented the application independently, working with my wife, a receptionist at the facility, to understand daily operations. Conversations with the finance manager helped confirm requirements and expectations.
The goal is a connected workflow: staff should be able to move from a reservation to room assignments, pet records, and check-in or check-out without losing the operational context.
Real stakeholders. A public demo. Juniper Boarding is a generic demo edition of this independently developed application. It preserves the reservation rules and permissions while using fictional data. Replacement of the facility’s legacy system remains a planned outcome.
02 / CONNECTED WORKFLOWS
One stay, several moving parts.
A boarding reservation connects customers, pets, room capacity, health records, and staff permissions. The interface and backend need to express those relationships consistently.
Reserve & assign
Boarding reservations, availability, multi-pet room assignments, and sharing rules.
Know the guest
Customer and pet profiles, vaccination records, and diagnostic records.
Manage the day
Arrivals, departures, current guests, overdue checkouts, and check-in/check-out.
Control access
Staff permissions and authorized manager overrides with audit histories.
03 / RESERVATION CORRECTNESS
Two requests.
One remaining space.
A successful availability check does not guarantee a successful reservation. Two requests can read the same remaining capacity before either writes a booking, allowing both to pass a check that was individually correct.
The implementation uses database transactions and pessimistic row locks to serialize bookings for the affected room types. Capacity is checked while the relevant lock is held, so a competing request checks the updated state after the preceding transaction finishes.
One space. Two requests.
Requests A and B arrive for the same room type. There is one remaining space. Each booking must check capacity inside its transaction.
Illustrative simulation of the implemented locking strategy. This walkthrough does not execute database requests.
The tradeoff: correctness over simultaneous writes.
Competing bookings for the same affected room type may wait for one another. That contention is the cost of coordinating capacity checks and writes around a shared resource.
04 / CONTROLLED EXCEPTIONS
Exceptions should be explicit.
Real operations sometimes require a manager to make an exception. The application supports authorized overrides alongside the regular reservation rules, including multi-pet sharing constraints.
Permission. Reason. Attribution.
Overrides require the appropriate role and record both a reason and the responsible user in the audit history. That makes an exceptional decision visible and attributable.
It is an intentional business path with accountability built into it, rather than an unexplained change to reservation data.
In the public demo, attribution identifies the shared Receptionist or Manager account. Visitors share the workspace and may see each other’s changes.
05 / TESTING & DELIVERY
More than a working interface.
The project includes frontend and backend automated tests using Jest, Vitest, React Testing Library, and Playwright. Docker and pnpm support the development workflow.
The stack combines Next.js, React, Mantine, and TanStack Query on the frontend with NestJS, TypeORM, and PostgreSQL on the backend, plus JWT authentication.
The public demo runs on Vercel, Render, and a separate Neon PostgreSQL database. A guarded reset workflow in GitHub Actions is scheduled daily at 3 a.m. Central Time. Resets restore fictional records and end existing demo sessions.
06 / WHAT’S NEXT
Finish, validate, learn.
The remaining story is operational: complete development, validate the workflows with facility stakeholders, and prepare for the planned replacement of the legacy application.
This case study currently focuses on the implemented behavior and design decisions. Usage metrics and rollout outcomes will belong here once they can be measured.
Explore the implementation The screenshots show the Juniper Boarding demo with fictional data. A compact demo notice and expandable Demo guide explain the shared workspace. Try creating a reservation, checking in a guest, or exploring an audited manager override.
Enter as Receptionist or Manager. Shared fictional data is scheduled to reset daily; no messages or payments are sent. After inactivity, please allow about a minute for the demo to wake up.
What’s next
Good software starts
with a conversation.
I’m interested in full stack, frontend, and backend engineering roles.
Have something in mind? I’d like to hear about it.