Hospitality / Booking Platform
LYLO RESORT
A full-stack resort site with booking, accounts, an admin area, payments, email notifications and a responsive UI.
- Year
- 2026
- Status
- Live
- Category
- Hospitality / Booking Platform
- Stack
- Next.js, TypeScript, Tailwind CSS
The brief
Overview
A booking platform for a resort that was taking reservations through direct messages and a shared spreadsheet. The goal was one system that shows the property properly, takes a booking end to end, and lets staff run it without touching code.
Problem
Availability lived in one person's head. Double bookings got caught by hand, rates changed by memory, and every enquiry turned into a separate conversation. Guests could not see what was free or whether their booking had gone through.
Solution
Availability is modelled in the database and checked on the server. Guests go from picking a room to a confirmation without leaving the site, and staff manage rooms, rates and reservations from an admin area.
Request path
One request, start to finishWhat actually happens between a click and a response.
- 01 / Client / Guest picks dates
- The form validates as you type so the feedback is instant, but nothing it says is trusted. Every rule it checks is checked again on the server.
- 02 / Server / Route handler
- POST to a route handler. The browser never talks to the database directly, so there is no connection string anywhere near the client.
- 03 / Server / Validation
- Zod parses the payload against the same schema the form uses. Unknown rooms, reversed ranges and impossible dates stop here with a 422 and a per-field message.
- 04 / Data / Availability re-check
- The overlap check runs inside the write, not from the page that rendered the form. Two people can reach checkout for the same night; only one of them can win.
- 05 / Data / MySQL
- Prisma writes the reservation. A unique constraint on the room and date range is the last line of defence if the application logic ever misses.
- 06 / External / Payment callback
- The provider posts back server to server. The reservation only becomes confirmed once that callback is verified, so a closed browser tab cannot lose a paid booking.
Features
06 items- 01
Availability-aware booking
Date selection is checked against live availability on the server before a reservation is written, so overlaps get rejected instead of reconciled later.
- 02
Accounts
Guests sign in to see upcoming and past stays. Sessions are issued server-side and kept in HTTP-only cookies.
- 03
Payments
Checkout runs through a hosted provider. The reservation is only confirmed once the provider's server-side callback is verified.
- 04
Email
Confirmations and status changes are sent from server routes, separately from the request that triggered them.
- 05
Admin
Rooms, rates, images and reservations are all editable. None of it is hardcoded in the UI.
- 06
Responsive
The gallery and booking widget are laid out differently on mobile rather than scaled down. The calendar becomes a stacked flow.
Architecture
- 01
Frontend
Next.js App Router. Server components for the property and listing pages, client components only where there is real interaction.
- 02
API
Route handlers for availability, booking creation and payment callbacks. Every write is schema-validated first.
- 03
Data
Prisma over MySQL. Rooms, rates, reservations and users are relational, with constraints that stop conflicting stays.
- 04
Auth
Hashed credentials, server-issued sessions, and authorization checked on pages and API handlers alike.
Technology
- Next.js
- TypeScript
- Tailwind CSS
- Prisma
- MySQL
Screens
SchematicsNo screenshots have been uploaded for this project yet. The plates below are generated schematics, not captures of the interface.
Challenges
- 01
Two people, one room, same moment
Availability had to be re-checked inside the write, not trusted from the page that rendered the form.
- 02
Dates, not timestamps
A stay is a range of local calendar dates. Normalising at the boundary stopped bookings shifting a day when read back.
- 03
Payment state vs booking state
A payment can succeed after the browser closes, so confirmation is driven by the verified callback rather than the client.
Result
Rooms, rates and reservations live in one system that staff run themselves, and a guest can book without a single manual message.