Budgets for connected-hardware projects are almost always built around installation: the devices, the integration, the app that drives them. The part that gets underestimated starts the day after — when the system has to run on its own, in places where nobody is standing.
The costs that appear after installation
- Connectivity: a data plan per unit, plus what happens when signal drops
- Remote updates, so a fix does not mean a site visit
- Monitoring: someone or something has to notice a unit went quiet
- Field intervention, which stays the most expensive line in operations
- Spare parts and their lifecycle, which does not match the software's
- Process changes as the fleet grows — what works at ten units does not at a hundred
Why the mobile app is not a detail
In a connected system the app is the only surface the end customer sees, and often the only one the operator sees too. If unlocking takes too long, or the status on screen does not match the state in the field, the problem arrives at support as a hardware fault. Diagnosing it then costs many times what fixing it would have.
A connected system is judged by what happens when the connection drops, not by what happens when it holds.
What gets decided early and paid for late
Three decisions taken in the first weeks account for most of the running cost later: whether devices can be updated remotely, whether they report enough to diagnose a fault without a visit, and whether the system behaves sensibly when it loses its connection. All three are cheap at the start and awkward to retrofit once the fleet is deployed — they are the decisions we settle at the start of any hardware–software integration project.
