Blog - Building for Low Bandwidth: What Shipping Software in East Africa Taught Us
When we shipped the first version of a field operations tool for a logistics client, we tested it thoroughly on our Kampala office Wi-Fi. It was fast, clean, and responsive. Then we watched a field agent try to use it on a 3G connection outside Gulu, and we realised we had built the wrong thing.
The app timed out loading the dashboard. Uploading a delivery confirmation photo took forty-five seconds. The offline fallback we had promised never actually worked. That experience reshaped how we think about frontend performance.
Bundle size is a feature
In markets where many users are on mobile data and pay per megabyte, a bloated JavaScript bundle is not just a performance problem — it is a cost problem for your users. We started treating bundle size as a first-class product metric. Every dependency gets scrutinised. We removed a charting library that added 180 KB for a single bar chart and replaced it with a small SVG utility. We split routes aggressively so users only download what they actually visit.
The result was a 60% reduction in initial load size, which translated directly to faster time-to-interactive on constrained connections.
Optimistic UI and offline-first patterns are not optional
When a network request might take five seconds or fail entirely, you cannot wait for a server response before updating the UI. We adopted optimistic updates broadly — the UI reflects the action immediately, and we reconcile with the server in the background. If the request fails, we roll back and notify the user.
For the field operations tool, we implemented a service worker that cached the core application shell and queued mutations when offline. When connectivity returned, the queue flushed automatically. Field agents stopped losing work to dropped connections, and support tickets dropped significantly.
Images deserve their own strategy
Images are almost always the largest assets on a page, and the default approach — upload whatever the user provides and display it — is a performance disaster on slow connections. We now run all uploaded images through a processing pipeline that generates WebP variants at multiple sizes, stores them on a CDN, and serves the smallest appropriate size based on the user's viewport.
For user-generated content like delivery photos, we compress aggressively on upload. A photo that arrives at 4 MB gets stored as a 200 KB WebP. The information is preserved; the bandwidth cost is not.
The broader lesson
Building for constrained environments forces discipline that improves your software for everyone. The same changes that made our field operations tool usable over 3G also made it faster over fibre. Performance is not a market-specific concern — it is a quality concern. The East African context just makes the cost of ignoring it impossible to dismiss.