HOSPOS Talk to us

Twinlite Services · hospitality systems, written in-house

The building. The guest. The shift.

Three systems that take the running of a hotel off paper and out of people’s heads. Halo minds the building. Lark minds the guest. Clocky minds the shift.

Built for The Bolton — an 84-room hotel in Dublin 1 opening Q1 2027 — and written so the next property is a configuration file, not a rebuild.

One property,
two sources of truth.

Mews knows the rooms. Entra knows the people. Everything our systems do is derived from those two — nothing is re-keyed, nothing is kept twice.

Every wire is a live integration — an API call or a webhook, never a nightly file drop. Lark is the only one that reads both: it needs the reservation from Mews and the device policy from Intune to know whose room it is sitting in.

Where they meet.

Three products only earn the word “suite” at the points where they touch. There are three, and each one is a join rather than an export.

One housekeeping queue.

Halo opens the make-up-room assignment the moment presence drops on a checkout day. Lark drops the guest’s own switches — do-not-disturb, make up the room now — onto the same Flexkeeping board, and holds them pending until housekeeping completes. The housekeeper works one list, and neither system knows or cares which of them filled it.

Mews hears it once.

Halo maps every room to its Mews resource and reads occupancy from the reservation. Lark writes the guest’s DND state and make-up-room note straight back to Mews, and reads the folio live rather than caching it. Two products, one reservation — there is no second copy to go stale.

One device estate.

Lark’s room tablets and Clocky’s handsets sit in the same Entra tenant and the same Intune estate, provisioned by policy. A new room, or a new starter’s phone, is a configuration entry — not a visit from someone with a cable.

Three systems.

Separate codebases, one operating philosophy. Every number below is a real setting in a running repository — thresholds, not aspirations.

Halo

Minds the building.

A ceiling sensor in every room reports presence over MQTT. Halo joins that to the Mews reservation, then decides three things without anyone asking it to: whether the room is empty enough to clean, whether the air needs conditioning, and whether something has gone wrong. Housekeeping gets a task the moment a departure is confirmed; the BMS gets the guest’s state immediately, not on a timer.

Halo technical specification
PresenceSteinel True PresencePoE, ceiling-mounted, one per room
TransportMQTT / TLS 8883QoS 1, broker on-premise
Checkout debounce15 minbefore a departure is called
Housekeeper debounce5 minbefore the clean is closed off
HVAC vacant guard60 soccupied writes go immediately
Pre-conditioning60 minahead of check-in
Environment alerts1400 ppm · 28 °C · 70 %RHCO₂, overheat, humidity — with hysteresis
Frozen-sensor watch3 hcatches a wedged head that keeps talking
Alert routing7 event groupsTeams Adaptive Cards, self-serve subscriptions
Failure modepersistent outboxexponential backoff — a cleaning task is never lost

Lark

Minds the guest.

The in-room phone is a line rental, a handset, and a reason to call reception about something reception can’t see. Lark is the tablet that replaces it: reception on one tap over the room’s own SIP registration, requests that land in Flexkeeping as tasks, the live folio straight from Mews, and express checkout that doesn’t need a queue at the desk. Unconfigured, it still runs — every screen works on canned fixtures.

Lark technical specification
DeviceAndroid tablet, per roomIntune dedicated-device lock task
ClientFlutter, Android-firstone store package serves every room
Voicein-app SIP → UniFi Talkno gateway server at the property
Dialable1 extensionreception, deliberately — nothing else
Languages4English · Français · Español · Deutsch
API surface11 handlersPOST JSON, per-device key auth
Refresh30 s pollno realtime transport, by decision
Offlinequeued on devicerequests replay on reconnect
Guest actionsrequests · info · folio · checkoutfolio read live from Mews, never cached
Device guardBLE exit beacona tablet leaving the building says so

Clocky

Minds the shift.

Hours are the largest controllable line in a hotel and the least instrumented. Clocky verifies every clock-in three ways at once — GPS geofence, the site’s own WiFi BSSIDs, and a live photo — and still never blocks the worker: anything unverifiable goes to a manager queue with a timestamp and a face attached. Because the roster and the clock share a table, planned-versus-actual is a join rather than a second version of the truth.

Clocky technical specification
Verification3 independent signalsGPS geofence · WiFi BSSID · live photo
IdentityMicrosoft Entra ID SSOno separate accounts, no passwords
BackendCloudflare Workers · D1 · R2no servers to patch
ClientsiOS & Android, nativeSwiftUI and Jetpack Compose, one API
Directory syncdaily, 05:00 UTCan Entra group is the roster
Payrollweekly, Mon 06:00 UTCCSV to R2, plus export for any range
Photo retention90 dayspruned by the same cron that exports
Offlinequeued clock-insa dead spot is not the worker’s problem
Test suite150 passingAPI + verification logic, CI-gated

What stops happening.

We don’t have a headline savings figure yet — the property opens in 2027. What we can name precisely is the work each system removes, and where it used to sit.

How we build.

The interesting engineering in a hotel is not the happy path. It is what the building does at 3 a.m. when an API is down, a sensor has wedged, or the Wi-Fi has dropped in a stairwell. These are the rules all three codebases keep.

Dry-run is the default.

Halo runs the whole lifecycle with no cloud credentials — every outbound call is logged instead of sent. A new property is exercised end to end before it is ever connected.

An outage is a delay, not a loss.

Failed writes land in a persistent outbox and retry with exponential backoff. Sensor and HVAC paths carry on regardless.

Every device works alone.

Lark serves canned fixtures with no backend at all. Clocky queues clock-ins offline and replays them. Connectivity is our problem, never the guest’s or the worker’s.

Watch the watchers.

A wedged sensor that keeps republishing identical readings is invisible to silence-based health checks. Halo flags it frozen after three hours — and refuses to invent vacancy from it.

Log what matters, block nothing.

Boot, session, request, call, checkout, error — all audited. A failure to write the audit line never stops the thing the person was doing.

Built to move.

Nothing here is welded to one building. Room maps, debounce thresholds, extensions, sites and languages are configuration. The second property is a config file.

What we plug into

Come and see it running.

Halo
Built and CI-green. Runs the full lifecycle against live Mews, with Prometheus metrics and a Grafana board. Flexkeeping writes are coded and waiting on the API key.
Lark
Published to Managed Google Play on 17 July 2026, org-restricted to Twinlite. Full guest journey in four languages; SIP voice proven end to end, inbound and outbound.
Clocky
Built on both platforms with 150 tests passing, plus a browser panel for managers. Verified in simulator; distribution via TestFlight and Managed Google Play.

We will walk you through a live room — sensor to BMS, tablet to reception, clock-in to payroll — and show you the code underneath it.

Arrange a walkthrough