Skip to content

technology

· · 4 min read

Designing for the Connectivity Gradient

Internet access in emerging markets is a gradient, not a binary. Here is how Nyuchi designs every product so the same software works on a 4G Macbook in a city office and a 2G Tecno on a verandah.

By Bryan Fawcett

Most enterprise software is designed in places where the internet is binary: on or off, fast or absent. That is not the experience most of our customers have. In every emerging market we ship into — Harare, Lusaka, Maputo, Manila, Karachi, Dhaka — the internet is a gradient: broadband at the office, 4G on the commute, 2G on the verandah, nothing in the car park, broadband again at home. Software that assumes the binary breaks at the edges of the gradient and quietly punishes everyone who lives there.

We design every Nyuchi product against six rules that exist because the gradient exists. They are not aspirations — they are how we ship.

1. Reads work without a connection

A user who lands on a Nyuchi screen with no signal should still see data. We pre-fetch what they are likely to need, cache it on the device, and update it when the network is back. The user does not have to know about any of this. The interface does not display a spinner; it displays the last-known state.

2. Writes queue locally, reconcile when able

If a clinic in Mutare submits a patient record while the cell tower is busy, the write must not be lost. We log every write to an on-device queue with a deterministic ID, then reconcile in the background when connectivity returns. Conflicts are resolved with the last-write-wins rule against the server timestamp, with one exception: clinical records are append-only.

3. The JS budget is 100KB per route

Every route in every Nyuchi app ships under 100KB of JavaScript on the wire. That is not a vanity metric — it is what a Tecno Spark on 2G can pull down before the user gives up. We achieve it by defaulting to server-rendered HTML (Astro), shipping React only for genuine interactivity, and aggressive code-splitting at the route boundary.

4. Outdoor-readable contrast and 56-pixel touch targets

The verandah at noon is the worst-case display environment we optimise for. Body text holds APCA Lc 90+ on its background. Touch targets are 56 pixels by default, 48 pixels absolute minimum — well above the WCAG 2.5.5 floor. The site works in midday Harare sun.

5. Multi-language parity from day one

English, Shona, and Ndebele are first-class. Strings are externalised from the first commit, layouts reflowable, voice flows recordable in the user's language. We do not treat English as default and other languages as second-class — and we treat translation as a literacy problem, not an engineering footnote.

6. Shared-device aware

In most clinics we work with, one tablet serves five clinicians. In many households, one phone serves five family members. Account switching is a primitive, not an enterprise feature gate. Every session is bounded by an explicit log-out, and personal data never leaks across switches.


What this looks like in practice

The Nyuchi API Platform — our developer-facing surface — exposes identity, payments, messaging, geo, and AI primitives behind one credential. Every primitive obeys the rules above. Reads cache. Writes queue. The SDK is 18KB gzipped on the wire. The mobile fallback uses SMS where data is unavailable.

The Nyuchi Medical product — clinic records, scheduling, tele-consult — is built on the same primitives. A patient registration submitted when the tower is down still prints a receipt; the record syncs when the network returns. The clinic does not stop because the network does.

This is what we mean by frontier infrastructure. Not a brochure phrase — a set of architectural choices that hold up where the internet is intermittent and the stakes are real.


Further reading

If you want to talk to a person — sales, integration, partnership — mail hello@nyuchi.com.