LuxuryStay

The idea

A hotel looks simple from the outside: a guest books a room, arrives, stays and leaves. Behind that sit a dozen small rules. A room must never be sold twice for the same night. A guest should not be allowed to leave with an unpaid bill. A room that has just been used must be cleaned before the next arrival. Many small hotels hold these rules in people's heads and in spreadsheets.

LuxuryStay puts those rules into the system. We built it as a complete showcase, with a guest website and a staff dashboard on the same data, so it shows how one system can serve everyone in a hotel.

How we approached it

We designed from the hotel's day, not from a feature list:

• One source of truth. The website and the dashboard use the same API and the same database, so a booking made by a guest at midnight is on the front desk's screen in the morning.
• The system protects the hotel. The rules that cause real losses (double booking, unpaid check-out, a dirty room at check-in) are enforced by the system, not left to memory.
• Each person gets only what they need. Three staff roles, each with its own screens and permissions, and guests who can read only their own bookings.
• Fast, clear, and calm to use. A guest should book in three steps. A front-desk user should check someone in with one click.

What guests can do

• Search by dates and party size, and see what is free and the exact price with tax.
• Open a room page with a photo gallery, amenities, a rating breakdown and reviews.
• Book in three steps (stay, guest details, payment) with a live price, paying at the hotel or choosing "pay by card" (a demo option).
• See upcoming, past and cancelled stays in an account area, cancel for free until the day before arrival with an automatic refund, and review a stay after check-out.
• Print an invoice, edit a profile and change a password, in a light or dark theme.

What the hotel staff can do

• Dashboard: occupancy tonight, arrivals and departures with one-click check-in and check-out, money collected, average daily rate, revenue per available room, and a 14-night forecast.
• Reservations: search, filter, sort and page through every booking. Open one to see its bill, charges, payments, refunds, room changes and history.
• Walk-in and phone bookings with a live price quote.
• Room calendar: every room, night by night.
• Rooms and housekeeping boards: cleaning status flows into the check-in checks.
• Guests, monthly reports with CSV export, and settings for tax, weekend uplift, check-in and check-out times, room types and staff accounts.

The rules the system enforces

• Prices are in rupees per night, and Friday and Saturday nights cost 10 percent more. Tax is a demo value of 13 percent. Both are settings, and each booking keeps the tax rate it was made with.
• A stay is limited to 30 nights, and check-out day is free.
• A room is assigned inside a database transaction, so two guests can never get the same room for the same night.
• A guest can cancel for free until the day before arrival, and what they paid is refunded automatically. Staff can cancel at any time.
• Check-out is blocked while a balance is due, unless staff collect it or choose to leave it open.
• Check-in warns when the room is not clean, and staff can override.
• Checking out marks the room dirty and creates a housekeeping task. Finishing that task marks the room clean.
• A cancelled or no-show booking owes nothing.

How it is built

• Front end: React 19 with Vite, Tailwind CSS 4 and Radix UI for dialogs and menus. The charts are drawn by hand in SVG. The staff application is a separate bundle, so guests never download it.
• Back end: Node.js with Express 5 and SQLite, using Node's built-in SQLite so there is nothing to compile, with input validation on every request.
• Security: passwords are hashed with scrypt, sessions are signed tokens, every staff route checks the role, the API sets secure headers, logins are rate limited, and guests can read only their own bookings. In production mode the server refuses to start without a real secret.
• Fonts: Cormorant Garamond for headings and Inter for text, hosted with the site.

Decisions worth explaining

• SQLite, on purpose. It keeps the demo to one command with nothing to install. The data layer is plain SQL in a few files, so moving to PostgreSQL or MySQL is a contained job. We first used a native SQLite package, and when it needed a C++ build toolchain on a clean machine, we replaced it with Node's built-in SQLite so the demo would run anywhere.
• Dates are plain YYYY-MM-DD values handled in UTC, and "today" comes from the hotel's own time zone (Asia/Karachi). No browser time zone can shift a booking by a day.
• Money is whole rupees, stored as integers, so totals never carry fractions.
• One error shape across the whole API, with a message next to the right field, so the forms can show clear help.
• The server receives its database, settings and clock from outside, so tests can control time and data.

How we checked it

• 41 automated API tests covering pricing, availability, bookings, roles, and the check-in and check-out rules.
• A browser script that drives the real website: a guest books a room, the front desk checks them in, a charge is added, check-out is refused until the balance is collected, and housekeeping cleans the room.
• A seeded sample hotel, so the demo looks the same every time it is reset.

Honest limits

This is a showcase, not a hotel in a box. The card option only records a payment, no emails or SMS are sent, there is one hotel with one currency, and the tax rate is a demo value. The room photos are from Pexels.

What a real hotel would need next

A payment gateway, email and SMS for confirmations, more than one property or currency if needed, backups and monitoring, and the hotel's own rates, taxes and policies.

What this shows about how we work

We find the rules that cost a business money and make the system enforce them. We keep the first version simple enough to run in one command, and we say clearly what is left for a real client. That is how we would approach your system.