Smart Lock Architecture for Boarding Houses and Hotels

Boarding houses and hotels can share a smart-lock backend while updating access differently. An on-site boarding-house manager can reach doors over Bluetooth. Hotel reservation changes often call for remote updates through a gateway that connects locks to the network. Choose by operational needs and define what happens when connectivity fails.

I've built one access platform that serves both. The interesting part of the design isn't the lock hardware. It's deciding where the network sits in the critical path, and for which building that decision is even worth its cost.

Two buildings, two constraints

A boarding house (kos) owner wants something cheap to install and little additional infrastructure to maintain: no wiring, no per-floor hardware, no dependency on the building's internet connection. A hotel wants the opposite: access rights that update the instant a booking changes, remote visibility into every door, and a system tied into how the front desk already works.

Serving both with one fixed architecture means either overbuilding the kos or underserving the hotel. So the platform doesn't have one architecture. It has two tiers on one core — an integration API, a mobile app, and an admin side that both tiers share — with the physical connection to the lock deciding how each tier behaves.

The BLE-only tier: the phone is the network

For boarding houses, locks talk pure Bluetooth. There is no gateway, no hub, no hardwired bridge. The manager's phone is the entire transport layer (like a courier carrying a physical key door to door, just digital). Creating a PIN, revoking a credential, pulling a log — all of it happens by standing at the door with the app open and letting Bluetooth complete a direct handshake with the lock.

That sounds limiting until you notice what it buys you: the lock never needs internet to make an access decision. Credentials are checked inside the lock itself, so a tenant's PIN still works during a WiFi outage, a router reboot, or a stretch with no connectivity to the building at all, because the door was never depending on that connectivity in the first place. The backend only matters for the paperwork around access, not the access itself: it tracks who holds which credential, when it should expire, and what the logs said the last time a phone synced.

The tradeoff is that revoking access is not instant. If a PIN needs to disappear right now, someone has to physically visit the door, because the manager's phone has to be there to push the change.

For a resident manager checking doors daily, that's not a real limitation — it's the same trip they'd make with a physical key. For an owner running several properties from a distance, it's a real gap, and it's the signal that the BLE-only tier is no longer enough. I go deeper on the credential mix and the tenant lifecycle in smart door access for boarding houses.

The hotel tier: gateways buy a system, not just a lock

Hotels get locks connected through gateways: small bridges, usually one per floor, that keep every lock reachable without a phone standing at the door. That constant reachability is what turns a lock into part of a system instead of a standalone device. The backend knows battery level and lock state in real time, and it can push a credential change without anyone walking a hallway.

The part that actually matters commercially isn't the gateway. It's what the gateway makes possible: access rights driven by the hotel management system instead of managed by hand. Room assignment at check-in issues the guest's access automatically, tied to the length of their stay. Checkout requests revocation through the gateway. Mark it complete only after the lock confirms the update; an offline lock may continue accepting the credential until it receives that change or the credential expires.

Housekeeping state — clean, dirty, inspected, out of service — stays visible alongside lock state, so a room isn't marked ready to sell while the door itself is still in an inconsistent state.

This is the same lifecycle discipline I've written about for hotel room status as a state machine: access, like housekeeping, is a state that has to be modeled explicitly, or it turns into someone's manual checklist.

Which tier to sell, and why forcing the other one is a mistake

The deciding question is who is physically at the building, and how fast access needs to change. An on-site manager who can reach any door in a few minutes doesn't need a gateway. They need cheap hardware and an app, and a gateway on every floor would just be recurring cost for a problem they don't have.

A hotel requiring immediate remote access updates when bookings change needs a communication path to the locks. A gateway supplies that path for BLE models. Hotels can also use reception-issued offline cards or locks with built-in networking; those choices have different revocation and update workflows. Operational requirements, rather than the label “hotel”, determine whether the selected system requires a gateway.

Selling the wrong tier shows up fast either way. A kos with gateways is paying for remote control nobody exercises, because the manager is already on site. A hotel using these BLE locks without gateways may need front-desk staff to update credentials at the doors — exactly the manual coordination a management system exists to remove.

The takeaway

One platform, two tiers, one deciding question: does the building have someone on site who can reach any door in minutes, or does access need to change the instant a booking does?

Boarding houses answer that with a phone and a Bluetooth lock. Hotels needing remote updates for these BLE models answer it with gateways linked to the booking lifecycle. The backend, the integration API, and the mobile app stay the same underneath. Only the connection tier, and what it plugs into, changes.

For the backend architecture that ties protocols like this together, see the complete guide to IoT backends.