Hotel and property operations
Availability, rates, reservations, arrivals and the bill that accumulates against a stay — with housekeeping and the front desk working from the same picture of which rooms are actually usable right now.
Talk about scopeAvailability is the only number that matters, and it is never simple
A room is not free or occupied. It is booked, held, occupied, being cleaned, out of order, or blocked for maintenance, and the answer to "can I sell tonight" depends on all of those plus the ones arriving and leaving today. Overbooking by one room is a real cost paid at the front desk by a person, and underselling is invisible revenue lost. Everything else in a hotel system is downstream of getting that single calculation right and keeping it right while several people change it at once.
- Occupied
- 9
- Departing today
- 3
- Being cleaned
- 2
- Held, unconfirmed
- 2
- Out of order
- 1
- Sellable tonight
- 3
What we would build
Each of these is a decision rather than a feature, and each one is expensive to change later.
- Room state as a first-class object, including cleaning and out-of-order.
- Rates as time-bound rules, so a stay prices against what applied when it was booked.
- A folio that accumulates charges across the stay and splits at checkout.
- A booking that survives changed dates, a room move and a partial cancellation.
- Housekeeping and reception reading the same state, not two copies of it.
- Group and corporate bookings, which break every model built for one guest.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.