One Smart Lock Platform, Two Very Different Buildings

One Smart Lock Platform, Two Very Different Buildings

A boarding house and a hotel both want doors that open for the right person and stay shut for everyone else. Past that, the requirements diverge completely.

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 nothing 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 revokes it the same moment, with no separate step for the front desk to remember and no window where a departed guest's credential is still live.

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 cannot run on the BLE-only tier at all: check-in and checkout happen continuously, guests expect access the moment they're handed a room, and there's no manager available to walk a hallway every time a booking changes. The gateway isn't an upgrade for a hotel. It's the minimum for the access lifecycle to track the booking lifecycle at all.

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 without gateways means someone at the front desk manually creating and destroying credentials all day — 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 answer it with gateways wired into 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.