When a connected product slows down, the tempting answer is to “optimize the app”. But in complex environments the app is often only the visible part of the system.
In one Dutch AgriTech project Altabel worked on, the product connected field hardware, sensor data, weather stations, mobile and web applications and a monitoring dashboard for farmers. Our work included refactoring the existing application, upgrading the Flutter app, integrating new features and building a React/TypeScript dashboard.
The useful question in such projects is not only “what should we improve next?”
It is: 𝐰𝐡𝐞𝐫𝐞 𝐝𝐨𝐞𝐬 𝐭𝐡𝐞 𝐜𝐨𝐧𝐬𝐭𝐫𝐚𝐢𝐧𝐭 𝐚𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐥𝐢𝐯𝐞?
A dashboard may feel slow because of frontend logic, but also because field data arrives inconsistently. A mobile flow may look like a UX issue, but depend on what the hardware can capture. A backend modernization may be technically correct, but still not change much if the data model reflects old assumptions.
That is what makes connected products different from pure software products.
You are not optimizing one layer. You are checking how hardware, firmware, connectivity, backend, interface and real field conditions affect each other.
Otherwise, the team may polish the most visible part of the product and leave the real limitation untouched. And that is why optimization has to start before the app layer.
11 Août 2026 à 08h30
Voir sur LinkedIn →
