Building AI Systems for Low-Connectivity Markets: Lessons from Nigeria

A large share of AI product infrastructure — chat UIs, streaming responses, session state held in memory — quietly assumes a stable, continuous connection. That assumption is invisible when building and testing on office WiFi. It becomes very visible the first time a system reaches users on prepaid mobile data with connectivity that comes and goes mid-conversation, which is daily reality for a large share of Nigerian SME owners using systems like BOS Afora.

Treat message delivery as unreliable by default

On a stable connection, delivery failures are rare enough to treat as edge cases. On intermittent mobile data, they're routine, and a system that doesn't account for that will silently lose messages, double-process retries, or leave a user mid-transaction with no clear state to recover from. Every inbound message needs idempotent processing — so a retry never produces a duplicate sale record or a duplicate charge — and every outbound response needs a durable queue with retry and backoff, not a fire-and-forget call that silently fails if the connection drops at the wrong moment.

Data cost is a user-facing constraint, not a backend metric

Where mobile data is a real, felt cost per megabyte, payload size becomes closer to a pricing decision than a performance one. A verbose response, an oversized image, a chatty back-and-forth that could have been one well-structured message — these translate directly into money spent by a user often running a small margin business. This pushes toward deliberately compact responses: text over rich media where text does the job, batched information delivery over multiple round-trips, images sized for the audience's bandwidth reality, not the engineer's.

Design for asynchronous, interruption-tolerant conversations

A chat interface implicitly assumes the user is present and will see a response within seconds. That breaks constantly in low-connectivity conditions — a user loses signal walking into a building, and doesn't see the response for twenty minutes, possibly after sending a follow-up with no idea a response is still pending. Conversation state has to be explicit and persisted, not implicitly held in an in-memory session that assumes continuity, so a user picking a conversation back up after an hour doesn't confuse the system's understanding of what's already been said.

Out-of-order and duplicate messages are routine, not exceptional

Intermittent connectivity doesn't just delay messages — it reorders them, and a retry from the client side after a timeout that actually succeeded can deliver the same logical message twice with different timestamps. A system that assumes messages arrive once, in order, will misinterpret a delayed message as the most recent one, or double-record a transaction from a retried send. Idempotency keys generated client-side (not server-assigned after the fact) and explicit sequence handling — rather than trusting arrival order — are what keep this from silently corrupting state.

This is the same idempotency requirement covered in idempotency keys for AI agents that take actions. For what this looks like from the product side rather than the infrastructure side, see how to do bookkeeping with BOS Afora.

Frequently asked questions

How do you prevent duplicate transactions when a message gets sent twice?

A client-generated idempotency key attached to each logical action, checked against recently processed keys before recording anything new, is the standard fix — the server recognizes a retried send as the same action rather than a new one, regardless of how many times the underlying message actually arrives.

Does this only matter for WhatsApp-based products?

No — any system with a mobile-first user base on variable connectivity faces the same problem, regardless of channel. WhatsApp is a common channel for MSME-facing products in Nigeria generally, but the underlying reliability patterns apply to SMS, push notifications, or any other asynchronous delivery mechanism.

Why this makes the system better everywhere

None of these patterns are market-specific hacks. Idempotent processing prevents duplicate transactions regardless of connection quality. Durable queues make a system more resilient to any transient failure, not just mobile network drops. Persisted, gap-tolerant conversation state handles a user stepping away from their desk for an hour just as well as a dropped mobile connection. Designing for the harder environment first produces a more reliable system across the board — it's not a compromise made for one market, it's what makes the system dependable for everyone.

Christian Chukwuka

Founder & AI Systems Engineer