Dormitory leasing, front desk, and billing in one system

The problem

This building is two businesses sharing a staircase.

Part of it operates like a hotel: nightly rooms, furnished, utilities included, guests arriving and leaving constantly. The rest operates like a landlord: year-long residential leases, minimum one-year contracts, and — critically — individual water and electric submeters on each unit, billed on top of rent. Any given room can be switched between the two models depending on demand.

Those two businesses have almost nothing in common operationally. One is turnover and housekeeping; the other is contracts and receivables. They were being run on spreadsheets and a logbook, which meant the answers to the three questions that actually matter — which rooms are free tonight, who owes us money, and what did this tenant consume — each lived somewhere different and had to be assembled by hand.

Submetered billing is where this gets genuinely difficult. Each unit’s monthly invoice is rent plus a consumption figure derived from two meter readings taken at the right time by the right person. Done on paper, that is a recurring, error-prone data-entry task where every mistake is a conversation with a tenant about money.

What we built

One system, five staff roles, and a public booking page.

Reservations become leases become invoices. The chain is modelled properly rather than re-entered at each step. A booking that converts into a residential lease generates its own invoices; payments settle against those invoices; the receivables position falls out of the same records that run the front desk. Occupancy and cash position stop being two separately-maintained truths that disagree by the end of the month.

Submeters are first-class. Readings are captured per unit and carried through into the invoice automatically, so a month’s billing is a review step rather than an evening of arithmetic.

A workspace per job. Front desk sees arrivals, departures and today’s board. Housekeeping sees rooms needing turnover, and nothing financial. Accounting sees invoices, payments, official receipts and reports. Management sees across all of it. Each role is scoped at the database level, so the boundaries hold rather than depending on which screen someone happened to open.

Units are configurable, not hardcoded. Because any room can flip between nightly and monthly, the unit type and its rate are configuration rather than assumption. The building can rebalance toward whichever model is performing without anyone touching code.

A payment flow that matches how people actually pay. There is no online card gateway, because the guests here pay by GCash, Maya or bank transfer. So the system accepts what really happens: the guest uploads a receipt screenshot, and a staff member validates it before the unit is held. That is deliberately not the “modern” answer — it is the one that matches the market, and it means the business isn’t paying gateway fees on transactions that were going to happen over a messaging app regardless.

A public booking page. Guests check availability and request a room from their phones, rather than messaging and waiting for someone to check a logbook.

Why it was built this way

The temptation with mixed-use property is to build two systems, or to force one model to pretend it is the other. Both are expensive. Modelling the unit as the shared primitive — with the business model as a property of the unit rather than of the system — is what lets one platform serve both without either side feeling bolted on.

Access control is enforced in Postgres row-level security rather than in the interface, which matters in a building where housekeeping staff and accounting staff use the same application on the same devices.

The whole system runs on Cloudflare’s edge, so the public booking page is fast for a guest searching on mobile data — which is the moment the booking is won or lost.

The result

The front desk, the housekeeping board and the books are the same system. Availability is live rather than reconstructed. Invoices — including submetered utilities — are generated from recorded activity instead of assembled by hand, and official receipts and accounting reports come from those same records.

Every staff role has its own tested surface, with browser-driven tests covering the sign-in and denial paths for each one: the suite asserts not only that accounting can reach the reports, but that housekeeping cannot.