Hidden Leaves · 2026
Booking stays and tours
Shippedhiddenleaves.scrocle.cloudIndependent engineer
The demo's dark-mode homepage, captured from the live site. The search card takes the trip details; the quote is assembled on the server.
The operators needed a complete booking product: find a stay or a tour, reserve it, manage an account, and leave a review. A brochure site with a third-party booking widget covers the catalog and stops there. It carries one permission level, and a widget prices rooms in the visitor's browser, where the quote is an editable suggestion.
The constraint
The public demo has to prove the product without showing real customer details or exposing an admin route. Login details for the demo are printed on the live page.
Built with
Next.jsTypeScriptPrismaNextAuth
How it works
Public catalog and reservation flow sit on Next.js. Mutations go through NextAuth, then Prisma. Price quotes are server-only. Reviews wait for moderation.
The calls that shaped it
Each decision with the pressure that forced it and the price it keeps costing.
One product for three roles
A third-party booking widget bolts onto a brochure and carries one permission level. The operators needed guests, staff, and admins inside the same flow, each with permissions of its own.
One Next.js application covers the public catalog, the reservation flow, and the staff surfaces. Staff tools are pages of the product with their own role checks, so a feature ships once and reads the same data as everything else.
The cost: Permission logic is part of every feature from the first commit. There is no separate admin app to retrofit rules onto later.
Prices are computed on the server
A booking quote assembled in the browser is an editable suggestion. Anyone can open devtools, and on a public demo someone will.
Amounts are calculated on the server. The browser receives the quote and displays it.
The cost: Every price display is a round trip, and the client holds no authoritative number of its own.
Roles live in the mutations
A role badge in the interface proves nothing. The network tab is right there.
Guest, staff, and admin are checks on the server's write paths. Submitting a review and publishing one are different permissions, so a review waits for moderation before it appears.
The cost: Every write path carries its own check, on the server, every time.
One schema, sessions beside the queries
NextAuth needs the same account records that Prisma queries. Keep them in two places and they drift.
Stays, tours, reservations, and accounts sit in one Prisma schema, and NextAuth sessions resolve against the same records. A role check sits next to the queries it protects.
The cost: The schema is the contract. A role change is a migration and a code review, and there is no setting to flip.
What shipped
Live pages from the demo, captured in its dark theme: the running product with sample data where real customer data would sit.
Open it and use it as a guest would. The login page prints the demo account, so you can skip straight in: sign in, land on the guest dashboard, and browse stays, tours, and reviews with server-computed prices.
Where it stands
Shipped and live. A private deployment starts from this codebase with the demo sanitization removed: the same product against real inventory and real staff roles.
- The site is live at hiddenleaves.scrocle.cloud with destinations, packages, hotels, activities, offers, and reviews, plus help and legal pages.
- The demo account printed on the login page signs in and lands on the guest dashboard with Overview, My bookings, and Wishlist.
- The demo discloses itself: a banner states that no real bookings or payments are made, and the reviews it shows are labelled as samples.
- Deliberately left out of the public demo: real customer data, payment processing, and any admin route.
What was handed over
- Source and schema
- Role map and which mutations each role may call
- How to run locally and how the production host is started
- What is sanitized in the public demo versus a private deployment