One Address Is Not One Device

Here is a data model that is completely correct, right up until it isn't: an address owns one hub, and that hub owns some sensors.

One property, one hub, some sensors beneath it. For a connected-property platform serving single-family homes, this is not a compromise. It is an accurate description of the thing. A house has an address, the address has a hub, the hub has sensors on the floor and by the boiler.

Then somebody asks for an apartment building.

Nothing breaks, which is the problem

An apartment building needs more than one hub, because one cannot reach every place a sensor has to sit. A school needs one per block. A commercial site needs several.

The model does not refuse this. Nothing errors. There is no capacity limit — the database will happily hold more devices. What it refuses is the shape: a hub belongs to an address, so a second hub needs a second address.

So the workaround appears on its own, without anyone deciding on it. The building gets entered as several addresses. It works, in the sense that the sensors report and the alerts arrive.

And then the costs arrive, none of which look like a schema problem:

• Support sees three customers where there is one building.
• Nobody can answer "how many sensors does this school have" without knowing which address records are really the same school.
• Installers carry the floor-to-address mapping in their heads, because there is nowhere to write it down.
• A property manager with forty units is being asked to manage forty customers.
• Every property-level report is wrong in a way that requires local knowledge to correct.

Each of these gets handled as its own operational annoyance. None gets filed as a bug, because nothing is broken. The model is just describing something that isn't there.

The address was doing two jobs

When we went looking, the limit was not capacity and it was not a missing feature. It was one relationship carrying two responsibilities that had been merged while nobody could tell them apart.

The address record was the property. The address record was also the parent of exactly one device. Those are different things, and as long as every property has one hub, there is no observation that distinguishes them.

This is how schemas age. It was not wrong when it was written; it encoded an assumption that was true at the time. The assumption stopped being true, and because the encoding was implicit, the cost surfaced as friction spread across support, installation and reporting rather than as a defect anyone could point at.

Separating them

The fix was to let the address be the property, and let hubs be devices belonging to it — as many as the building needs, each with its own sensors underneath.

That is the whole change. Everything else followed from it.

Bulk installation became possible, because an installer could commission a building as one property with hubs added to it instead of repeating a new-customer flow per hub. Property-level reporting became possible, because there was now a property to report on. And existing homes needed no migration at all — a house with one hub is the new structure with a single child, which meant devices already in the field kept working through the change. That last point is not a small one when the devices are the ones expected to notice a burst pipe.

The general version

When a product is straining to reach a new kind of customer, the obstacle is usually described as a missing feature. Sometimes it is. Often it is a relationship that quietly encoded the old kind of customer, back when there was only one kind.

The two look similar from the outside and cost very different amounts to fix, in both directions. A genuine feature gap is usually bounded work. A wrong relationship is cheap to change early and expensive later — not because the migration is hard, but because by then a good deal of surrounding code, tooling and operational habit has been built on top of the workaround, and all of it has to be unpicked.

So the question worth asking before building the feature: is this customer asking for something the system cannot do, or something the system cannot say? If it is the second, the feature will be a workaround, and you will be maintaining it for years.