We've spent enough time doing scheduled and emergency maintenance on off-grid IoT installations around Kisumu that a few lessons have become consistent enough to be worth writing down, rather than just carried around as institutional memory. None of these are secrets. They're the kind of thing that's obvious in hindsight after the third time it happens, and invisible before the first.
The failure you didn't design for is the one that happens
Every installation gets engineering attention on the failure modes that are easy to imagine: battery depletion, sensor drift, connectivity loss. In practice, a meaningful share of maintenance callouts are things nobody explicitly designed against: a cable gland worked loose by vibration nobody accounted for, insects nesting inside an enclosure gap that was technically within spec but not actually sealed under real conditions, a mounting bracket that corroded faster than expected because it was in intermittent contact with lake water splash that the original site survey didn't fully anticipate. The lesson isn't "engineer for everything," which is impossible. It's "build in enough visibility that you find out about the failure you didn't anticipate quickly, rather than discovering it only when the unit has already been silent for weeks."
Maintenance access is worth real design effort, not an afterthought
Every hour spent making a unit easier to service in the field saves multiples of that hour across the unit's actual service life, because maintenance visits are expensive in a way that's easy to underestimate at design time: travel to a remote site, weather-dependent access, and the opportunity cost of the technician's time all add up. A design choice that makes a battery swap take five minutes instead of forty, or that clearly labels which connector is which so a technician isn't guessing, pays for itself many times over across a multi-year deployment.
Scheduled maintenance is cheaper than reactive maintenance, every time
This sounds obvious stated plainly, but it's easy to under-invest in scheduled maintenance when a system has been running fine for months. A planned visit to check connector integrity, clean solar panels, verify battery health, and confirm calibration is a controlled, budgeted cost. An emergency visit after a unit has gone silent, especially if it's gone silent during exactly the weather event that made its data most valuable, costs more in every dimension: more urgent travel, more diagnosis time on-site because you don't know what's wrong yet, and a gap in the data record for however long the unit was down.
Documentation quality determines how fast a fault gets fixed
A unit that fails in a way that's clearly diagnosable from its logs or a simple status indicator gets fixed on the first visit. A unit that fails silently, with no record of what led up to the fault, often takes a second visit once the right diagnostic question has been figured out. Investing in good local logging and simple status indication at design time is, in our experience, one of the highest-value things we've changed based on real field experience, precisely because it turns a mystery into a checklist.
Every site is a little different, and that's fine
It's tempting to want one standard design that works everywhere. In practice, cage sites, land-based ponds, and gateway installations each have their own combination of mounting constraints, power availability, and connectivity, and a standard design deployed without accounting for a specific site's realities tends to become the standard design that needs the most maintenance visits. What scales well isn't a single rigid design; it's a consistent design process, and a maintenance-friendly philosophy, applied to each site's specific constraints.
Why we keep publishing this
None of this is proprietary. We write it up because the lessons are genuinely useful to anyone maintaining field hardware in this region, and because a maintenance history you can point to, honestly, including the parts that didn't go perfectly the first time, is worth more to a prospective partner than a claim of flawless reliability nobody would believe anyway.
If you're planning a field deployment and want a maintenance-minded second opinion before it ships, or already have hardware in the field that needs a maintenance partner, get in touch. You can also see how we take hardware from prototype to the field.
