Skip to content
Industries

Insurance software that stops the claim, not just settles it.

iLeaf builds the software layer of connected-property insurance: sensor onboarding, the policyholder app, the alert path and the carrier integrations behind it. We engineer the platform behind a home-telematics product used by North American property carriers, where a sensor detecting water at 2am is worth more to everyone than a fast claim the following week.

Ask Lia about insurance

What this includes

Property telematics platforms
Sensor hubs, leak, freeze, temperature and power-loss monitoring, and the alert path from device to policyholder, monitoring centre and carrier.
Co-branded policyholder apps
The carrier's brand on an app it did not have to build — or the same telematics stack embedded inside the app it already has.
Device onboarding that survives a kitchen
Wi-Fi provisioning that works for a policyholder who is not technical, on the phone they actually own, including the ones released last month.
Multi-device property modelling
One address, many hubs, many sensors — what an apartment block, a school or a commercial site needs and a single-home model cannot express.
Carrier & monitoring integrations
Getting an event out of a sensor and into the systems that act on it, at the reliability an alerting path has to hold.
Claims and sensor data analysis
Joining device telemetry to claims history, which is what turns a smart-home gadget into an underwriting input.

How we run it

Every phase ships something usable on its own, so you are never holding a half-finished system waiting on the next milestone.

  1. The alert path is the product

    A sensor that detects and does not reach anyone has done nothing. We engineer for the notification arriving, not the reading being taken.

  2. Assume the policyholder is not an engineer

    Onboarding is where connected-property programmes are won or lost. A device that will not pair is a device that gets returned.

  3. Model the property, not the device

    Address as the parent entity, hubs beneath it. It is the difference between serving houses and serving buildings.

  4. Design for the carrier's own systems

    Telematics only changes loss ratios if the events reach underwriting and claims. That integration is the work, not an afterthought.

What we build it with

  • Swift
  • Kotlin
  • React Native
  • BLE
  • SoftAP provisioning
  • MQTT
  • AWS IoT
  • Node.js
  • PostgreSQL
  • Push notification infrastructure
  • Penetration testing
  • OpenTelemetry

Questions we get asked

Do you build the sensors as well?

No — we build everything above them. Hardware partners make the devices; we engineer the pairing, the mobile app, the alert path, the property model and the carrier integrations. On a home-telematics platform we also handle the part that breaks most often in practice, which is a device failing to connect on a phone or OS released after the hardware shipped.

Can this sit inside our existing policyholder app?

Either way. We have delivered co-branded applications that carry a carrier's identity end to end, and the same telematics layer embedded into an app a carrier already owns. The second is usually the better answer when you have an app policyholders already have installed.

Does connected-property telematics actually reduce claims?

The evidence is promising and it is worth reading properly rather than taking on trust. Our client in this space published a multi-year actuarial analysis, run with a major insurance consultancy across six carriers and more than 175,000 policy years, reporting fewer and less severe water-loss claims among households with an active leak sensor. That is their study of their programme, not a guarantee for every book of business — but it is real actuarial work rather than a vendor claim, and it is the right shape of question to ask before funding a programme.

What does a property with multiple buildings need?

A property model that does not assume one address means one device. We rebuilt exactly that relationship on a home-telematics platform: the address became the parent entity with multiple hubs beneath it, each with its own sensors, which is what an apartment block, a school or a commercial site requires. It is a data-model change rather than a feature, and it is the difference between selling to houses and selling to buildings.

Let’s talk about insurance.

Tell us what you are running and what it needs to do next. We will tell you honestly whether we are the right team for it.

Talk to a solutions lead