Building AirConnect: Designing for Low-Bandwidth Africa

In Zambia, booking a domestic flight still routinely means going to an airline office in person. That is the problem AirConnect exists to solve. Building it has forced us to confront a set of constraints that most booking software quietly assumes away.

The network is not a given

Booking flows built for reliable connections make an implicit promise: each step will complete before the next begins. On an intermittent mobile connection that promise breaks constantly, and a booking flow that breaks halfway is worse than no booking flow — the customer does not know whether they have paid.

The design consequence is that every step has to be resumable. State lives locally as well as on the server, so a dropped connection mid-flow means picking up where you left off rather than starting again. The interface has to tell the user plainly what has and has not been confirmed.

Payload size is a product decision

When data costs money, every unnecessary kilobyte is a small tax on your user. That reframes technical choices as product ones: aggressive image compression, minimal client-side JavaScript, and search results that return only the fields the list actually renders rather than whole objects.

It also means being disciplined about what loads eagerly. A rich interactive seat map is a lovely feature and a poor default on a metered connection.

The offline case is not an edge case

Once a ticket is issued, the customer needs it at the airport — a place where connectivity is often at its worst, and where "let me just reload the page" is not an acceptable answer. Digital tickets have to be available on-device without a round trip.

That pushed us toward caching confirmed bookings locally as soon as they are issued, and treating the network as an enhancement rather than a requirement for anything the customer has already paid for.

Trust is the real barrier

The hardest problem is not technical. Asking someone to pay for a flight through an app, when the alternative is handing money to a person at a desk who gives them a printed ticket, is asking them to trust a process they cannot see.

The response has been to make every step visibly concrete: immediate confirmation, a ticket that exists on the device rather than only in an inbox, clear reference numbers, and a real phone number to call. None of that is clever engineering. It is just taking the user's uncertainty seriously.

What this has taught us about client work

Running our own product changes how we build for other people. Every shortcut we might have been tempted to take, we now have to live with ourselves — including three years from now, when someone has to maintain it. That is a useful discipline, and it is the main reason we keep building products of our own alongside client projects.

AirConnect is in active development. If you operate in travel and want to talk about integrating, we would like to hear from you.