In 2023, I worked on a livestock monitoring platform as part of my internship at Optimizer. The goal was straightforward: give farmers real-time visibility into their animals’ location and health. The execution was anything but.
This is what building a cross-platform IoT system taught me.
The Architecture Was the Hardest Decision
We had to support three interfaces: a web dashboard, a mobile app for field use, and IoT devices attached to animals. Each had different constraints.
The tech stack ended up being:
- Angular for the web frontend
- Android/Kotlin for the mobile app
- C# / .NET for the RESTful backend
- PostgreSQL for data persistence
- MQTT for device communication
- Docker for deployment
The decision that mattered most was MQTT. We chose it over HTTP polling because the devices needed near-real-time updates without draining batteries. That choice paid off repeatedly.
What I Learned About MQTT
MQTT is not complicated in theory. A broker, topics, publishers, subscribers. But the details matter:
Topic design requires discipline. We started with flat topics like animal/123/location. By the time we had fifty devices, it was unmanageable. We switched to hierarchical topics: farm/42/paddock/7/animal/123/gps. This let us subscribe at different granularities and made the system much easier to reason about.
QoS levels are not optional. We used QoS 1 for location data and QoS 2 for health alerts. This meant some location messages could be lost without breaking the system, but health alerts were delivered exactly once. Understanding the tradeoffs here prevented data corruption later.
Last Will messages are essential. When a device goes offline unexpectedly, the broker publishes its LWT message. We used this to detect device failures within seconds instead of waiting for a timeout. Every IoT system should use this pattern.
The Cross-Platform Reality
Building for web, mobile, and IoT simultaneously means making compromises that frustrate everyone.
- The web team wanted rich visualizations with real-time updates.
- The mobile team needed offline capability for areas with poor reception.
- The IoT devices had kilobytes of RAM and could only send small payloads.
The solution was not to find a perfect architecture. It was to accept that each platform would have a different experience and build the integration layer to handle those differences gracefully.
The Real Test
The system worked. Farmers could see their animals on a map, receive alerts when an animal left its paddock, and track health metrics over time.
But what surprised me was what the farmers actually used. They cared most about the alerting system, not the dashboards. They wanted to know when something was wrong, not stare at charts all day. We had spent a lot of effort on beautiful visualizations. The real value was in the event-driven notifications.
Another lesson: build what users actually need, not what you think is impressive.
What I Would Do Differently
Looking back, a few things I would change:
- More time on offline support. The mobile app relied too much on connectivity. A local SQLite cache with sync logic would have been better.
- Less time on custom visualizations. Off-the-shelf mapping libraries would have covered 90% of the use case.
- Earlier testing with real devices. We spent months testing with simulated data. The real devices behaved differently. Always test with real hardware as early as possible.
This project taught me that IoT is not about the technology. It is about making the technology invisible so the user can focus on their actual job. That principle applies everywhere, not just on farms.