How we built an offline-first door-access device
A meeting-room door that enforces reservations by itself — and keeps working when the network doesn't. The engineering story behind our Business Avenue access appliance.
Business Avenue, Iraq's leading serviced-office provider, bills meeting rooms by reservation. That sentence hides a hard problem: if the booking says the room is yours from 2 to 3, the door itself has to agree — open for you, stay shut for everyone else, and remember what happened. We built the management platform that takes those bookings. Then we had to get them to the door.
Why off-the-shelf lost
Commercial access control assumes one of two worlds. Either a standalone keypad that knows nothing about your reservation system — so someone types the same master code for every meeting — or a cloud-connected controller that phones home before deciding whether to unlock.
The first world can't do the job. The second does the job until the internet hiccups — and anyone operating in Iraq plans for the hiccup, not the happy path. A door that stops working during an outage isn't access control; it's a locked-out client standing in front of a room they paid for.
The requirement, stated honestly: the door must make the right decision with no network, no server, and — for a while — no mains power.
The appliance
We ended up designing the whole object: a Raspberry Pi 5 with a 7-inch touchscreen in a case we designed ourselves, mounted at the door. A relay drives a magnetic lock. A USB RFID reader takes member cards; guests type the reservation code from their booking on the kiosk screen. A companion UPS unit — also ours, also custom-cased — keeps the door alive through power cuts.
The software is where the requirement gets satisfied. A Python device service (FastAPI) owns the door. It keeps a local SQLite cache of everything it needs — reservations, cards, schedules — and makes every single open/deny decision locally, against that cache, in milliseconds. The kiosk UI is a SvelteKit app served by the device itself; even the user interface doesn't need the internet.
Offline-first is a discipline, not a feature
When the network is up, the device runs three quiet loops against the Business Avenue backend: sync (pull the latest reservations and credentials), events (push what happened at the door), and heartbeat (tell the dashboard the door is alive). When the network is down, nothing changes at the door — decisions keep coming from the cache, events queue up locally, and everything reconciles when the connection returns.
Notice what the backend is not in this diagram: it's not in the decision path. The backend is for synchronization and management — pairing a new device to the dashboard, pushing over-the-air updates, collecting events. Permission lives at the door.
Building it like software, because it is software
A device you ship to a client's wall can't be debugged over their shoulder, so we built the whole thing to be testable without hardware. The device service runs against a hardware-abstraction layer with two implementations: real (GPIO and the RFID reader on the Pi) and mock (your laptop). A mock backend stands in for Business Avenue's API. The result: the full system — pairing, sync, decisions, kiosk UI — runs on a developer PC with no hardware at all, and 39 automated tests run against the device service on every change.
Provisioning is code too: Ansible and systemd turn a fresh Pi into a hardened kiosk — locked-down OS, auto-starting service, watchdog restarts — the same way every time. That's what makes it a fleet product rather than a one-off: door number twelve installs exactly like door number one.
What we'd tell you if you're considering custom hardware
- Start from the failure mode, not the feature list. "What happens when the network is down?" shaped this device more than any feature request.
- The case is part of the product. Designing our own enclosure let the hardware fit the door instead of the other way around.
- If you can't test it on a laptop, you'll test it on your client. The mock HAL and backend cost days and saved weeks.
- Fleet thinking from day one. Pairing, provisioning and updates are the difference between a prototype and a deployment.
The full case study — with the exploded renders and the UPS — is here. And if your business has a door, a machine or a process that needs software with a body, that's a service we offer.
Software that needs a body?
We design and build connected devices that integrate with your systems — and keep working when the network doesn't.