One Address, Many Hubs: Rebuilding a Property Model for Buildings

Our client is a North American home-telematics provider. Their connected sensors watch for water leaks, freezing pipes, temperature swings and power loss, and their property insurance partners distribute those sensors to policyholders. iLeaf has built and maintained the iOS and Android applications behind that product, including the sensor onboarding that decides whether a policyholder ever gets it working at all.

The applications were designed around a house. That assumption was correct for years, and then it stopped being.

The Challenge

The original data model was a straight line: an address had one hub, and the hub had its sensors.

One address had one hub. The hub had its sensors. For a detached home this is not just adequate, it is the right model — it matches the thing it describes, which is the most that can be asked of a schema.

It falls apart the moment a property needs more than one hub. An apartment building does. So does a school with a main block, a classroom block and an administration block. So does any large residential or commercial site where one hub cannot reach every place a sensor needs to sit.

Because the model tied a hub to an address, the only way to install a second hub was to invent a second address. A single building became three or four address records that happened to share a street name.

That workaround costs more than it looks like it should:

• The property stops being one thing. Reporting, alert routing and support all see separate customers where there is one building.
• Installers carry the mapping in their heads. Which address is the second floor is not written down anywhere the system can read.
• Nobody can answer a property-level question. "How many sensors are in this school" requires knowing which addresses are really the same school.
• It does not scale to the sale. A property manager with forty units is being asked to manage forty customers.

What We Found

The investigation did not take long, and what it found was not a capacity limit. Nothing in the platform refused to store more devices.

The limit was the relationship. The address record was doing two jobs at once: it was the property, and it was the parent of exactly one device. Those are different responsibilities, and while a property has one hub you never have to notice they have been merged.

This is the ordinary way a schema ages. The model was not wrong when it was written. It encoded an assumption that was true, the assumption stopped being true, and because nothing errored, the cost showed up as operational friction rather than as a bug anybody filed.

What We Built

We separated the two jobs. The address became the property entity — the school, the apartment block, the house — and hubs became devices belonging to it, each with its own sensors beneath it. A property can now hold as many hubs as it physically needs, and a hub is no longer pretending to be an address.

The apps were reworked around the same idea. A property is the thing you open; hubs are things inside it; sensors sit beneath their hub. Somebody looking at a school sees the school, with its blocks under it, rather than four unrelated entries that have to be recognised by address line.

Two consequences followed almost for free once the relationship was right.

Bulk installation became possible. An installer commissioning a building works through one property, adding hubs to it, rather than repeating the whole new-customer flow for each one. The tedious part of a large install was tedious because of the model, not because of the work.

Existing properties did not have to move. A home with one hub is the new structure with a single child. Everything already installed kept working without a migration event, which matters when the devices in question are the ones expected to notice a burst pipe.

The Result

The platform now supports multiple hubs and their sensors under one property address, and the apps present them that way.

• An apartment building, a school or a commercial site is one property record, however many hubs it needs.
• Sensors stay organised under the hub that owns them, so coverage is legible per building and per area.
• Large installations are commissioned as one job rather than as several unrelated ones.
• The product is no longer structurally limited to single-family homes.

The Part Worth Taking Away

The improvement was not support for more devices. The platform could always have stored more rows.

It was making the address the property and letting devices belong to it — a change to one relationship, from which the multi-building capability, the bulk install and the property-level reporting all followed. Before, the schema could only describe houses. After, it could describe buildings, and the same code served both.

When a product is straining to reach a new kind of customer, it is worth checking whether the obstacle is a missing feature or a relationship that quietly encoded the old customer. They look similar from the outside and they cost very different amounts to fix.