Design for Load Shedding

The most useful design constraint I have is that the electricity goes off.

Not as a disaster. As a schedule. Hours of it, most days, for months at a time depending on the water level at Kariba. Everyone here plans around it. Almost no software does.

Once you take that seriously, a lot of received product wisdom stops applying.

Continuous power, continuous connectivity and continuous cash are three assumptions, and all three are wrong here.

Start with connectivity. An app that requires a live connection to be useful is an app that is useless exactly when a person most needs it, which is out on a farm or down a road or in a district office at four in the afternoon. So the default is offline first. The application holds its state locally, works fully without a signal, and reconciles when it finds one. Sync is a background event, not a precondition.

Then payload. Data is expensive relative to income here, and people notice. A page that pulls three megabytes of fonts and hero imagery is charging the user real money to look at it. Nyimboo has to work for someone on a bus in Kabwata with two bars and a bundle they bought this morning. That single scenario removes most of what a streaming interface would otherwise carry.

Then the device. The phone in the hand is often three generations old with a battery that has been through several rainy seasons. Battery draw is a design constraint, not a footnote. Background location polling, aggressive prefetching and animation-heavy interfaces are not features here. They are ways to get uninstalled.

Then the channel. AgriNova's most important insight was not technical. It was that the extension officer who has to act on an advisory may be carrying a feature phone. So the intelligence can be as sophisticated as we like, but the last hundred metres has to be able to collapse to SMS or USSD without losing the instruction. If the advice cannot survive being reduced to one hundred and sixty characters, the advice is not finished.

Then money. Card penetration is low and mobile money is the real rail. Balances are lumpy, arriving with a harvest or a shift payment rather than monthly. Subscription pricing designed around a salaried customer will fail against a customer whose income arrives four times a year. Prepaid, bundled and small denominations are not downmarket compromises. They are the actual market.

None of this is a complaint. Constraints like these produce better engineering, because they force you to establish what the product genuinely needs in order to be useful. Software built to work with intermittent power, expensive data and old hardware also works beautifully in perfect conditions. Software built the other way round does not travel.

Build for the grid you have. It works on the grid you wish you had.

Every product I have shipped that ignored this had to be rebuilt. Every one that started from it has held up.