Architecture
Written for the person who has to approve it
If you are the IT director being asked to put someone else’s system into your buildings, this page is for you. What runs where, what talks to what, what happens when a part of it fails, and what we will not do to your network.
Design principles
Six decisions everything else follows from
These were not all obvious at the start. Several of them are the result of running a live estate for long enough to find out which shortcuts cost more than they saved.
Intelligence sits close to the room
Every layer holds enough state to keep doing its job when the layer above it goes quiet. A room module enforces its own policy without the gateway. A gateway keeps polling without the site server. A site keeps operating without the cloud. Losing a layer degrades the system; it does not stop it.
Data is pushed, not polled
Dashboards do not ask the server whether anything has changed — the server tells them. It is why an event reaches a screen in a quarter of a second, and why adding operators to a property does not add load in proportion.
Each property keeps its own data
Properties are not pooled into one shared database. Each keeps its own, and the central layer aggregates. Isolation is structural rather than a filter somebody has to remember to apply, and one busy property cannot slow another down.
Nothing reaches into your network
The property connects outbound to us. There is no inbound firewall rule to justify, no port forwarded to a controller in a floor panel, and no VPN concentrator for a hotel IT team to maintain.
Boring infrastructure on purpose
Standard server operating systems, a mainstream database, ordinary TLS and a reverse proxy. No container orchestration to learn and no exotic data store to staff for. A capable in-house IT team can run this if they want to — several do.
Everything is written down
Every meaningful action — a check-in, a command, an administrative override, a configuration change — is recorded with who did it, to what, with what payload and when. The audit log is not editable by any role, ours included.
The stack
Nothing here should surprise your team
We have deliberately not been clever about infrastructure. The platform runs on the same components a modern Windows or Linux shop is already running, on hardware you can specify yourself, with a deployment process that is a script rather than a platform.
There is no container orchestration requirement, no proprietary runtime and no managed service you are locked into. That is a deliberate constraint, and it is the reason a hotel group’s own IT department can take over day-to-day operation of their installation if they decide to.
- Application platform
- .NET 8
- Database
- SQL Server
- Realtime transport
- WebSockets, with fallback
- Authentication
- JWT, per-machine keys
- In transit
- TLS 1.2+
- At rest
- Transparent DB encryption supported
- Server OS
- Windows or Linux
- Containers required
- None
Site control-loop timing
- Event to coordinator
- Under 1 s
- Command acknowledged
- ~104 ms typical
- Offline device detected
- Within 5 s
- Segment polling cycle
- 500 ms, 64 rooms
- Dashboard update
- Under 1 s, pushed
- Full state rebuild
- Under 10 s, all 2,048 rooms
TCMsys figures, verified against the physical bus budget at full segment load.
When things break
Failure behaviour, stated plainly
Every system has a failure mode. The useful question is what it does when it hits one — so here is ours, without the hedging.
The property’s internet link
What keeps working
Everything in the building. Events queue locally and replay in order when the link returns — check-ins, checkouts and room moves are never blocked by a WAN outage.
The site server or coordinator
What keeps working
Room-level control and energy policy continue autonomously from the modules’ own stored configuration. Gateways keep polling, keep enforcing and keep recording.
One bus gateway
What keeps working
Only the rooms on that segment are affected. Every other segment is untouched — failure does not cascade.
A room module loses power
What keeps working
It restores its own configuration and re-applies the AC state within moments of power returning. The guest does not find a room that forgot what it was doing.
A firmware update goes wrong
What keeps working
The device stays on the firmware it already had and reports the failure. Updates are staged and checksum-verified before they are ever applied.
A server release goes wrong
What keeps working
The previous release was snapshotted before the swap. Rolling back is one command and seconds of downtime.
Security
What we do, and what is yours to do
We are the processor; you are the controller. That distinction matters, so we have been explicit about which side of the line each of these sits on.
Encrypted in transit
TLS 1.2 or better on every internet-facing path. Unencrypted remote access is not an option we offer, not a default we ship.
Encrypted at rest
Transparent database encryption is supported where a customer or a jurisdiction requires it.
Permission-gated endpoints
Authorisation is declared on the endpoint itself against a catalogue of granular permissions. Hiding a menu item is not access control and we do not treat it as such.
Structural tenant isolation
A portal user scoped to one property cannot read another’s data even through an endpoint that failed to filter — the scope is applied beneath the query, not inside it.
Session and account hygiene
Idle sessions expire. Repeated failed logins lock the account. Installer accounts expire on their own so a third party does not keep access after handover.
Immutable audit trail
Administrative actions are logged in a form no user role can alter, including the highest one. Irreversible operations require re-authentication.
Device identity
On-site services authenticate with per-machine keys. Bus address assignment is checked against the device’s factory serial, so a commissioned module cannot be silently reassigned.
You are the data controller
Occupancy and door events may be personal data in your jurisdiction. We document exactly what is collected and retained, and give you the tools to export and purge it by room or by date range on request.
Operations
How we run it
Fleet operations is where a building-control vendor either earns their retainer or quietly becomes your problem. These are the practices we hold ourselves to.
Events buffer on site
Activity is written to a durable queue inside the property’s own database before it is sent anywhere. The link can drop, the agent can restart, the server can reboot — the queue survives all three and drains in order when the connection returns.
Schema updates without a DBA
The on-site agent installs and versions its own database objects at startup. Rolling out a schema change across the estate does not require the customer’s database administrator to do anything.
Staged rollouts
Versions are assigned per property, so a release reaches a pilot group first. When a bad build has shipped, this is what has kept the blast radius to a handful of sites rather than the whole fleet.
Reversible deployments
Server releases are snapshotted before they are swapped in. A rollback is one command and a few seconds of downtime, which means we can deploy fixes quickly instead of carefully.
- Release rollback
- One command
- Deployment downtime
- Seconds
- Firmware update safety
- Staged, checksum-gated
- Failed update outcome
- Previous version retained
- Configuration backup
- On every change
- Site restore target
- Under 2 hours
Ask us for the retrospective. We keep an honest internal record of what went wrong at fleet scale and what we changed because of it. If you are evaluating us seriously, we will walk you through the relevant parts of it — including the incidents.
Send us your security questionnaire
We would rather answer it properly than have it sit in a procurement queue. Send the questionnaire, the network constraints and the deployment shape you have in mind, and we will come back with specifics.