The Mobile Architecture Behind a Connected-Property Insurance Programme

Our client is a North American provider of connected-property sensors. Their route to market is property insurers: the carrier funds the sensor, the policyholder installs it, and everybody hopes it notices a burst pipe before the ceiling comes down.

iLeaf was chosen to build the mobile applications that make that chain work. The brief was "an app to connect the sensors", which is the kind of brief that hides where the difficulty actually is.

The Challenge

The hardware existed and worked. The gap was everything between a sensor detecting water and a person doing something about it — and the mobile app sits in the middle of all of it.

Four things had to be true at once.

Pairing had to work for someone who is not technical. The policyholder is standing in a utility room with a phone, and they did not choose this product — their insurer sent it. If pairing takes three attempts, the box goes in a cupboard and the carrier has funded a sensor that watches nothing.

The alert path had to be reliable, not merely present. A sensor that detects a leak and reaches nobody has converted an undetected leak into an undetected leak with a log entry. The notification arriving is the product.

One app had to serve several carriers. Each wanted their own brand in front of their own policyholders. Building an app per carrier would have multiplied the maintenance by the number of clients.

It had to be defensible. The app knows where people live and when their property is empty. That is not a feature set to be casual with.

What We Built

Two ways to pair, because one is never enough. Wi-Fi provisioning used SoftAP, with sound-based provisioning as the fallback. Different homes and different phones fail differently, and having a second route turned a support call into a second attempt. Onboarding is the step with the highest drop-off in any connected-property programme, and the cheapest place to buy success is a fallback.

An alert path built for the worst case. Events travel sensor to hub to platform to notification, and each hop is somewhere it can silently stop. The app had to handle a hub reconnecting after a router reboot without anyone re-pairing it, because nobody re-pairs anything.

A white-labelled architecture. One codebase, several carrier identities, so a new insurance partner is a configuration rather than a project. This is the decision that made the commercial model work — the alternative is a codebase per client and a maintenance burden that grows with every sale.

Security treated as a requirement. We ran penetration tests across the mobile app and cloud and closed what they found. For an app holding property addresses and occupancy patterns, this is the baseline rather than a milestone.

The Migration

As the platform grew and white-labelled deployments multiplied, the infrastructure underneath it had to change: roughly 30,000 user accounts moved to a different cloud provider.

The interesting constraint was not the data. It was that this is a safety-adjacent product. A migration window where alerts do not arrive is not an inconvenience, it is the one thing the product exists to prevent. The alerting path had to keep working while the ground moved underneath it.

The Result

A consumer app that policyholders could actually onboard, delivered over about six months, with all users successfully migrated and the alerting path intact throughout.

For the carriers, the outcome is the one that matters: sensors that get installed and stay connected, alerts that arrive, and a branded experience they did not have to build. The programme has since grown into multi-building properties and newer device generations, each of which has needed its own engineering — but the architecture set here is what made those possible rather than a rebuild.

The Part Worth Taking Away

In connected-property insurance the sensor is the photogenic part and almost never the hard part.

The engineering that decides whether a programme succeeds is onboarding that survives a real utility room, an alert path engineered for the notification arriving rather than the reading being taken, and an architecture that can wear more than one brand. Get those right and the hardware gets to do its job. Get them wrong and you have distributed a great many small plastic boxes.