Pearl Trails
Lodges, campsites and experiences across Uganda: travellers discover a stay and request a booking; staff review and act on it in an operations console.
What it enables
- A traveller discovers a stay, checks availability for their dates, requests a booking and plans the trip around it.
- Staff sign in to an operations console to review requests, confirm, cancel or expire them, and edit the catalogue.
- Each consequential staff action is written to a history, so a booking’s story can be read back.
My contribution
Design and full-stack build: the public site, the booking-request flow, the operations console and the data model, deployed to Cloudflare Workers.
Decisions worth noting
No payment layer, on purpose
Payments were deferred and the product never implies one. The repository records what would need to be true before starting.
Constraints instead of locks
Overlapping bookings are rejected by a database constraint, which replaces SELECT … FOR UPDATE on a serverless Postgres connection.
State in the URL
The console’s search, filters and paging live in Postgres queries and the address bar, so a view can be shared and refreshed.
Stack
- Next.js
- TypeScript
- Cloudflare Workers
- Drizzle
- Neon Postgres
Boundaries
An MVP: no online payments, and bookings are requests that staff confirm.