Writing software for a building that loses power
A resort in far-western Nepal needed one system for reservations, housekeeping, restaurant and billing. The hard constraints had nothing to do with software.
When we started on the operations system for Sudurpashchim Resort, we did what you would expect: mapped reservations, housekeeping, restaurant, inventory, staff and billing, and started drawing schemas.
Then we spent time at the property, and the requirements changed.
Constraint one: the connection is not reliable
The resort sits in far-western Nepal. Connectivity is good enough most of the time and absent some of the time. A front desk that cannot check a guest in because the internet is down is not a system, it is a liability.
That pushes you toward one of two designs. Either the critical paths work offline and reconcile later, or the system is honest about being unavailable and staff have a paper fallback they have actually rehearsed.
Pretending the connection is always there is the one option that guarantees a bad night at reception.
Constraint two: the person using it is not sitting down
Housekeeping staff are moving through corridors with their hands full. They are not going to open a laptop to mark a room clean.
This is where a lot of hospitality software quietly fails. It is designed as a desktop admin panel and then squeezed onto a phone. The information architecture still assumes a big screen and a mouse.
Getting this right meant designing the housekeeping view phone-first and stripping it to almost nothing: which rooms are mine, what state are they in, one tap to change state. Everything else lives elsewhere.
Constraint three: one system, several very different jobs
A resort is not one business. Reservations, restaurant and bar, inventory, and staffing all have different rhythms, different users and different failure modes. Restaurant orders are high frequency and low value. Reservations are low frequency and high value. Inventory only matters when it runs out.
The temptation is to build four products. The reason not to is billing: a guest's final bill has to pull the room, the restaurant, the bar and anything else onto one folio. If those live in genuinely separate systems, someone reconciles by hand at checkout, and that person will make mistakes in front of a departing guest.
So: separate modules, shared ledger. Each part can be understood on its own, but they settle into one account.
The public site is part of the operation
The public site is not marketing sitting beside the system. It is the front door of the same system. Availability shown to a guest online has to be the availability the front desk sees, or you have built a machine for double-booking.
That is the argument for building both rather than buying a booking widget and bolting it on. One source of truth for what rooms exist and which are free.
What we took away
Software for physical businesses is mostly about respecting physical constraints. The interesting problems were not in the data model. They were power, connectivity, and the fact that the person using the housekeeping screen is holding towels.
You do not find those in a requirements document. You find them by standing in the building.
Building something like this?
We are a product studio in Kathmandu. Tell us what you are building and an engineer will reply.