Designing for weak networks and shared phones

Most software is designed in an office with fast Wi-Fi and a charger at every desk. A construction site in Kigali is a different place. Data comes and goes, one phone is often shared by a few people, and a battery that dies at noon stays dead until the evening.

We made a rule early on: if a feature only works on a good day, it doesn't work.

What can't we assume on a construction site?#

Three things came up on every site visit:

• Steady data. Coverage drops behind concrete and on upper floors.
• One phone per person. Many workers share a handset with family or crewmates.
• A charged battery. A phone that is dead can't be the key to the gate.

How does Buildpal keep working offline?#

The gate is the one place that can never wait for a signal. So the reader captures every tap locally and syncs when the network returns. The worker taps, the reader answers, and the record catches up later. The gate never stops.

The same idea runs through the rest of the product: capture first, sync when possible, and never lose a record because a connection dropped.

Basic phones are equal citizens#

Not everyone has a smartphone, and nobody should need one to be paid fairly. Workers without one get the same profile and the same record, with USSD and SMS for the things they need to check, like a booking or a payment.

What did we change after the first pilots?#

We made screens lighter, cut steps from the flows workers use most, and moved anything that needed a live connection away from the gate. Small changes, but they add up on a site where every minute at the gate is a minute not working.

We'll keep sharing what we learn in these field notes, including the things we got wrong.