How to Build a Hotel Booking Website: Rooms, Rates, Availability and Payments
How to build a direct booking site for a hotel or guesthouse: room types, nightly availability, rates, deposits, and avoiding overbooking.
Mythex Team · · 6 min read
A hotel booking website lets guests pick dates, see which rooms are free for every night of their stay, see the total price, and pay or place a deposit — without anyone emailing back and forth. To build one you need room types with a count of rooms, a nightly availability model, rates that can change by date, a booking flow that re-checks availability when it saves, and an admin view for the front desk. The hard part is not the pretty pages. It is making sure a room is never sold twice, especially if you also sell on booking platforms.
What the site needs
Pages
- Public: home, rooms (photos, beds, size, amenities, max guests), a date-and-guests search, results with total price per room type, a booking form, payment, and a confirmation page with a manage-booking link.
- Supporting: location and directions, policies (check-in times, cancellation, children, pets), FAQ, contact.
- Private (staff): arrivals and departures for today, a calendar grid of rooms by night, bookings list, blocked dates, rates and room settings.
Data
| Table | Key fields |
|---|---|
| Room types | Name, description, max adults and children, base rate, photos |
| Rooms | Room type, number or name, active yes/no |
| Rates | Room type, date or date range, price per night, minimum stay |
| Bookings | Guest, room type, assigned room, check-in, check-out, guests, total, deposit paid, status, source (direct, OTA) |
| Guests | Name, email, phone, country, notes |
| Blocks | Room, date range, reason (maintenance, owner use) |
Store check-in and check-out as dates, not times, and treat check-out as exclusive: a stay from the 10th to the 12th uses the nights of the 10th and 11th. Getting this wrong causes the most common availability bug.
Permissions
Guests see prices and whether a room type is available — never who else is staying. Front-desk staff see bookings and guest details; only the owner changes rates and policies. That means a staff login with at least two roles.
Decisions and trade-offs
Request to book or instant booking
Request to book — the guest sends dates and details, you confirm by email — is far simpler and is fine for a small guesthouse. Instant booking needs airtight availability and payment handling, but converts better. Many properties start with requests and switch later.
Sell room types or specific rooms
Guests usually book a room type ("Double with sea view"), and staff assign the actual room later. Selling specific rooms is simpler to build but makes the calendar harder to fill.
Rates
Start with one price per room type per night, with optional overrides for date ranges (high season, holidays) and a minimum stay. Leave dynamic pricing, promo codes and packages for later.
Payments
Options, in rising order of complexity: pay on arrival; a deposit through a hosted checkout such as Stripe Checkout; full prepayment for a non-refundable rate; or saving a card to charge later. Payment rules, taxes and tourist levies vary by country — check local rules or ask an adviser. Our payments guide covers the mechanics.
Other channels
If rooms are also listed on online travel agencies or holiday-let platforms, you must keep calendars in step. Many of those platforms can export and import calendars as iCal links; syncing that way is common for small properties but happens on a delay, not instantly. A channel manager is the professional answer.
A first prompt that works
Build a direct booking website for Harbour House, a 9-room guesthouse in Tobermory, Scotland. Room types: Double (4 rooms, 2 guests, £120/night), Twin (3 rooms, 2 guests, £115), Family (2 rooms, 2 adults + 2 children, £165). Guests search by check-in date, check-out date and guests, and see only room types with a free room for every night of the stay, with the total price. Check-out is exclusive. Minimum stay 2 nights in July and August. Booking form collects name, email, phone and arrival time; save it as "pending" and re-check availability on the server before saving. Staff area with login: today's arrivals and departures, a calendar grid of rooms by night, bookings list with status, and a way to block dates. Show check-in 3–8pm, check-out 10am and the cancellation policy (free until 7 days before) on every booking page. Calm coastal design, mobile-first.
Build steps
- Model rooms and nights first. Room types, rooms, rates and the availability check. Test it before any design work.
- Search and results. Date picker, guest counts, total price for the stay, clear "sold out" states.
- Booking flow. Form → server-side availability re-check → pending booking → confirmation page with a manage link.
- Staff area with login: arrivals, departures, calendar grid, block dates.
- Email confirmation through your own provider, with dates, total, address and policy. See sending emails.
- Deposits in Stripe test mode, confirming the booking only when payment succeeds. A payment webhook needs your app to be published at a public URL.
- Calendar sync with other channels if you use them, plus a daily manual check at first.
- Test the edge cases: two browsers booking the last room, a stay crossing a rate change, a cancellation freeing nights, one-night stays during a minimum-stay period.
- Publish and make a real booking yourself before switching off your old process.
Common mistakes
- Checking availability only in the browser. Two guests will eventually book the last room at the same moment.
- Counting check-out night as occupied (or not counting check-in night). Write a test for a two-night stay.
- One flat price. Most properties need at least seasonal overrides.
- Hiding the total until the last step. Show the full stay price, including any fees you know about, in the results.
- Policies buried in the footer. Show cancellation terms next to the pay button.
- Treating iCal sync as instant. It isn't; close dates by hand when you are nearly full.
When a ready-made product is the better choice
If you run more than a handful of rooms, sell through several online travel agencies, or need housekeeping, invoicing and reporting, a property management system with a built-in booking engine and channel manager is usually the right call. These products exist to solve overbooking across channels, and that is expensive to reproduce well.
A custom site makes sense for small properties that mostly take direct bookings, for unusual inventory (glamping pitches, cabins with shared facilities, rooms sold with activities), or when you want your own design and guest experience without a monthly fee per room. Some owners pair a custom website with a hosted booking engine embedded on it — often the best of both.
Building it with Mythex
On Mythex you describe the property in chat, review the site in a live preview (including a phone-size frame), and publish when it works. Bookings, rooms and rates live in a Postgres database the agent adds when the app needs to save data; it sleeps when idle and wakes on the next request. Staff login, email confirmations and deposits are wired to your own providers and keys — Mythex has no built-in end-user login, email or payments product — so read the Stripe recipe before you add deposits. Use /test to have the agent walk through search and booking, and checkpoints to roll back a change that breaks availability.
For a starting prompt, look at the hotel booking system builder, the guesthouse booking system builder or the glamping booking site template. For hourly or appointment-style bookings instead of nights, see the booking app guide.
Questions
How is hotel booking different from appointment booking?
Hotels sell nights, not time slots. You track how many rooms of each type are free on each night, a stay spans several nights, and the price can change night by night.
How do I avoid overbooking when I also sell on booking sites?
Every channel must share one availability source. Small properties often sync calendars by iCal links, which is not instant, so keep a buffer or close dates quickly. Larger properties use a channel manager that updates all channels in near real time.
Should guests pay in full when they book?
It depends on your policy. Common options are a deposit at booking, full prepayment for non-refundable rates, or a card saved and charged later. Whatever you choose, show the cancellation policy before payment.
Is a custom hotel booking site worth it for a small property?
For a small B&B, a custom site with a request-to-book or simple instant booking can work well. Once you sell on several online travel agencies or manage many rooms, a property management system with a booking engine and channel manager is usually worth its fee.