The most common architectural pattern for "smart" building products in 2026 is the same one social apps use: a thin client talking to a cloud backend that does the actual work. It's a great architecture for an app you check three times a day. It's a bad architecture for a system that has to keep a 22 °C room at 22 °C every minute for the next ten years.
Cynact runs local-first. The control runtime lives on an industrial edge node at the customer site. The cloud is where we manage fleets, push updates, and surface dashboards — but it is not in the critical path for the building doing its job.
What we actually mean by local-first
A local-first runtime, in our definition, satisfies four properties:
- Survives network loss. Every automation, schedule, and safety override executes without internet access. The site doesn't degrade — it just keeps running.
- Survives cloud outage. If Routbox's own cloud goes dark, the site continues as if nothing happened. State syncs back when the cloud returns.
- Sub-network-latency control. Decisions that need to happen in milliseconds happen in milliseconds, not on a 200 ms round-trip through a region in Virginia.
- Optional cloud, not required cloud. A customer can run Cynact entirely air-gapped for compliance reasons and still get most of the product.
Why this matters for utilities
Utility innovation teams are specifically asking for endpoints that hold up during grid events — heat events, ice storms, hurricane recovery. Those are exactly the moments when communications infrastructure is most likely to be impaired. A cloud-tethered building control becomes a brick at the worst possible time.
A local-first endpoint, by contrast, can be told via OpenADR or IEEE 2030.5 to shed kW, then continue shedding for the duration of the event even if it loses contact with the VTN — because the policy is already on the box.
Why this matters for residents
For homeowners and tenants, local-first is invisible until it isn't. Then it's the difference between "the heating still works because the modem is rebooting" and "the heating's off because Comcast." We don't market this directly — most people don't want to think about it. But it's why we built the foundations this way.
The trade-off
Local-first is harder to build. You need to design every feature for partition tolerance from day one. You need real state-sync engineering rather than treating every state mutation as a HTTP POST. You need to budget hardware for compute that a cloud-only product can offload.
We made the trade-off knowingly. The classes of customer we want to serve — utility partners, commercial operators, premium residential — all eventually ask the same question: what happens when the network fails? Local-first is the only answer that doesn't require a workaround.
More on the protocol layer in a follow-up. Reach out if you're a utility innovation team or a commercial operator with a deployment in mind — info@routbox.com.