Security & connected devices
One app for a fleet of devices that were never designed to agree
Connected security grew by accretion — a camera here, a sensor there, a lock from a third vendor. The engineering problem is rarely the hardware. It is giving a household or a site one coherent way to see all of it.
What the work is up against
01
Fragmentation reaches the customer
Users end up managing several disjointed apps for cameras, sensors and locks. The result is poor adoption of features the hardware already supports.
02
Video has no latency budget
A security feed that lags is not a security feed. Live streaming has to be genuinely low-latency across variable consumer networks.
03
Connectivity issues become support cost
Every device that silently drops off the network becomes a support ticket. Reliability work pays for itself twice.
What we build for security teams
Modular device hubs
React Native applications for iOS and Android that present cameras, sensors and locks from different vendors as one coherent system.
Low-latency video pipelines
WebRTC streaming engineered to stay responsive across variable consumer networks, because a lagging feed is not a security feed.
Serverless alerting
Event handlers that deliver mobile alerts instantly and cost nothing while idle, which matters when most devices are quiet most of the time.
Fleet provisioning at scale
Onboarding, identity and firmware management designed to work at the million-device mark rather than being retrofitted once it arrives.
Connectivity diagnostics
Surfacing why a device dropped off rather than only that it did, which is what actually removes the support ticket.
How we approach it
Treat fragmentation as a product problem
Multi-vendor hardware is a given in connected security; customers buy incrementally. The engineering task is not to eliminate that variety but to hide it, which is why the Lorex work centred on a modular hub rather than a rewrite of any individual integration.
Design for the network you actually have
Consumer connections are contended, lossy and highly variable. Video and alerting were built assuming that as the normal case, not the degraded one — the difference between a feature that demos well and one that survives a real household.
Count support tickets as an engineering metric
A 60% reduction in connectivity tickets is a product outcome, not an operations one. Reliability work on device state and reconnection paid for itself twice: once in retention, once in support headcount.
Delivered work
Lorex — Canada
A unified smart-security hub replacing several disjointed vendor apps with one modular control surface.
- Active devices under management
- 1M+Active devices under management
- Increase in daily active users
- 300%Increase in daily active users
- Fewer connectivity support tickets
- 60%Fewer connectivity support tickets
Questions we get from security teams
- We have hardware from several vendors. Is that a problem?
- It is the normal case, not an exception — customers buy connected security incrementally. The engineering task is to hide that variety behind one coherent interface rather than to eliminate it. A modular hub handles new vendor integrations without reopening the application.
- What latency is achievable on live video?
- Low enough to be usable as a security feed, using WebRTC rather than segmented streaming. The real constraint is not the protocol but the consumer network, so the pipeline is built assuming contention and packet loss as the default condition rather than the degraded one.
- Does this scale past a few hundred thousand devices?
- Provisioning, identity and firmware management have to be designed for the target scale rather than retrofitted once it arrives. The Lorex platform manages over a million active devices, and the decisions that made that possible were taken early.
- Will this reduce our support load?
- It should, and it is worth measuring as an engineering outcome rather than an operations one. Surfacing why a device disconnected, not merely that it did, is what removes the ticket. That work cut connectivity-related support volume by 60%.