Designing AI for low-bandwidth markets

Many AI products are designed in offices with fibre connections and tested on the latest phones. Then they meet a field officer in a rural district with a three-year-old handset and a patchy signal, and they stop working.

Designing for these conditions is not a niche concern. For much of the world it is the default. Here are the patterns we rely on.

Put the model where the user is

Large models belong in the cloud, but many useful tasks do not need them. Crop-disease detection, document capture and simple classification can run on the device with compact, quantised models. The user gets an answer immediately, and the heavy model can check the result later when the phone reconnects.

Queue, then sync

Every action a user takes should be saved locally first and synced when a connection appears. That means designing data models for conflicts from day one: what happens when two officers update the same farm record offline?

Degrade gracefully

When the best model is unreachable, the product should fall back to a simpler rule or a cached answer and say so clearly, rather than showing a spinner that never ends.

Watch the data bill

A single photo upload can cost a user more than they expect. We compress aggressively, upload only what the model needs, and let users choose to wait for Wi-Fi.

Test in the real conditions

We test on low-end devices with throttled networks, and in the field with the people who will use the product. It is the fastest way to find the assumptions nobody wrote down.

Language and voice matter

Text-heavy interfaces exclude many users. Voice input and output in local languages — with a clear way to reach a human — often do more for adoption than a better model.

None of this is exotic engineering. It is a matter of treating connectivity, cost and language as design inputs rather than afterthoughts. If you are building for these markets, let's talk.