Designing for Sri Lankan Connectivity Realities

We build from Minuwangoda, which means our team regularly experiences the conditions our software has to work in. That turns out to be a significant advantage, because the assumptions baked into most application architecture are written on excellent connections.

Offline is a data model decision

Treating offline support as a UI concern — a banner, a retry button — produces software that technically loads and cannot do anything. Real offline capability is decided in the data layer: what is cached, how writes queue, and how conflicts resolve when two devices edited the same record. Retrofitting that later usually means rewriting the client.

Optimistic UI, with an honest ledger

Our field applications record actions locally and reflect them immediately, then reconcile in the background. The crucial detail is a visible queue: users can always see what has synced and what has not. Hiding that state is where trust breaks — a driver who cannot tell whether a delivery was recorded will write it down on paper anyway, and now you have two systems.

Payload discipline

On a congested mobile connection the difference between a 180KB bundle and a 1.4MB bundle is the difference between usable and abandoned. We enforce budgets in CI, split by route, and serve responsive images through an edge CDN. It is unglamorous work with a larger effect on adoption than most features.

Test on the hardware people own

Our device shelf is deliberately mediocre — mid-range Androids several years old, because that is what a large share of users actually carry. Every release gets checked there before it ships. A build that feels smooth on a new iPhone and stutters on a four-year-old Android has not been tested; it has been admired.