Case study — hospitality operations software

Guesthouse
Booking Console

A booking-to-checkout system built for a family-run mountain guesthouse — a rolling room calendar across every channel, automatic room assignment, and per-stay pricing that adjusts itself, replacing a routine of Booking.com messages, a paper ledger, and a lot of memory.

Rooms9 (7 + 2)
Channels trackedBooking.com + Direct
CalendarRolling, no cutoff
NotificationsDay-ahead push
The starting point

Nine rooms, one inbox, one memory

Bookings arrived two ways — a Booking.com message thread, or a direct call or WhatsApp text — and both ended up in the same paper ledger by the front desk. Nothing stopped the same room from being promised twice across those two channels, and there was no shared view of who was actually arriving today, who still owed a deposit, or which rooms needed restocking after a checkout.
The brief was one board that both channels fed into, with a room calendar that couldn't silently double-book, and pricing that didn't need to be recalculated by hand every time a guest extended their stay or a family asked for an extra bed.
Front desk board

Every booking, one board

Four counts drive the whole front desk view — checked-in, arriving, paid and unpaid — and clicking one filters the list below it instead of opening a separate report. A stay is automatically treated as closed the day after checkout, regardless of its payment status, and moves itself to a separate tab without anyone updating it by hand.
Front desk — 4 active stays Interactive
Room assignment

The room assigns itself

Nine rooms — seven Standard (six with a balcony, one without) and two Apartament units — get matched to a new booking automatically, in a fixed order, rather than left to whoever's at the desk that day.
01 — REPEAT GUEST

Same room again

A returning guest's most recent room of that type is offered first, if it's free for the new dates.

→
02 — GROUP BLOCK

Rooms kept together

A family or group booking multiple rooms gets a contiguous run of room numbers, not whatever's scattered free.

→
03 — FIRST FREE

Fallback

Otherwise, the first free room of the right type — skipping anything blocked for maintenance.

Engineering notes

What made this harder than it sounds

Dates

Dates stay local, on purpose

The obvious way to handle a booking date is to hand the "YYYY-MM-DD" string straight to the browser's built-in date tools, which quietly convert it through a UTC timestamp on the way in and back out again. Depending on where the guest is and what time they book, that hidden conversion can bump a checkout date onto the wrong calendar day entirely. Every date here is read and written straight from its own year/month/day, with no timestamp conversion involved.

Calendar

A calendar with no edges

A fixed month grid cuts a stay in half the moment it crosses month-end. The room calendar scrolls as a continuous, rolling window instead, so a nine-night stay over a month boundary still reads as one uninterrupted bar.

Pricing

One catalog, two consumers

Room rates and the per-night extra-person charge both read from a single pricing catalog edited in one place. Guest count above a room's base occupancy is priced automatically — change the dates or add a guest, and the surcharge line recalculates itself rather than waiting to be re-entered.

Rollout

Useful before the backend existed

Built to run standalone on local demo data with no database configured at all, so the front desk could start using the board immediately — then switched over to a managed cloud database once the schema was ready, without changing how the screen worked.