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 insuranceWhat 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.
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.
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.
Model the property, not the device
Address as the parent entity, hubs beneath it. It is the difference between serving houses and serving buildings.
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.
Insurance: the work behind this

IoT
IoT-Powered Smart Home Mobile App | A Cutting-Edge Case Study by iLeaf Solutions
Simplifying the Smart Home. A leading company in the smart home domain had developed smart sensors for consumers. They now wanted to build a mobile app solution that would enable their consumers to connect the smart…
Read the case study
Insurance
One Address, Many Hubs: Rebuilding a Property Model for Buildings
The platform assumed one address meant one sensor hub. That is true of a house and false of an apartment block, a school or a commercial site — so a single building had to be registered as several separate addresses. Changing the address-to-device relationship is what took the product from homes to estates.
Read the case study
IoT
Restoring Sensor Pairing on the Newest iPhones With a Native Bridge
Sensor hubs paired normally on Android and failed on the latest iPhones. The vendor library at the centre of it had no fix available. A native bridge added the missing iOS behaviour at the application layer — keeping the existing integration and restoring pairing without waiting on someone else's release.
Read the case study
Logistics
AI Fleet Telematics for a Middle East Transport Authority
A bus and truck fleet where the data already existed — telematics, work orders, documents, parts — and no single view said what to do about it today.
Read the case study
