Designing software for Nigerian networks and power

Software that works perfectly on a fast office connection can fail badly in the real world. In Nigeria, users move between strong 4G, weak signals and no signal at all, often within the same day. Data bundles cost money. Power cuts interrupt offices and drain phone batteries. Many people use mid-range Android phones with limited storage.

None of this is a reason to build less ambitious software. It is a reason to build it carefully. Here are the choices that make the biggest difference.

Make it light

Every kilobyte costs your users time and money.

• Set a weight budget for each page or screen, and check it on every release.
• Compress and resize images for the screen they are shown on, and use modern formats.
• Load what is needed first. Delay images, scripts and features below the fold until they are needed.
• Use heavy frameworks only where they earn their keep. A simple content page does not need a large JavaScript bundle.
• Cache sensibly so returning users do not download the same files again.

Make it resilient

Connections drop. Good software expects it.

• Save drafts on the device as people type, so a lost connection never loses their work.
• Queue submissions made offline and send them automatically when the connection returns.
• Retry with care. Wait a little longer between each attempt, and design the server so a repeated request never creates a duplicate order or payment.
• Show sync status clearly, so people know what has been sent and what is waiting.

Make it forgiving

• Keep forms short. Ask only for what you need, and split long forms into steps that save as they go.
• Never clear a form on error. Show what went wrong next to the field and keep everything else.
• Tell people what happened. “Saved on this phone, will send when you are back online” is far better than a spinner that never ends.

Host it close to your users

Distance adds delay. Hosting an application far from your users, or sending every request through several countries, makes each action slower. Consider where your users are, and use content delivery networks, local data centres or nearby cloud locations for the parts that need to be fast. Where personal data is stored outside Nigeria, remember the Nigeria Data Protection Act’s rules on transfers.

Plan for power

• Office servers need a UPS and a backup power source, and should shut down cleanly before the battery runs out. For many organisations, moving critical systems to well-run hosting removes the problem altogether.
• Network equipment such as routers and switches should stay up when the power goes, or staff lose access to cloud systems even when their laptops still work.
• Mobile apps should be gentle on batteries: avoid constant background activity and frequent location checks unless they are essential.

Use SMS where it counts

For critical messages such as one-time passcodes, delivery updates or appointment reminders, SMS reaches people who are offline or have run out of data. Use transactional SMS routes for passcodes and service messages, as promotional routes can be blocked for numbers registered on the Do-Not-Disturb list.

Test like your users

Most bugs that matter in Nigeria never appear on a developer’s laptop. Test with:

• throttled connections, including long periods offline;
• real mid-range Android phones, not just the latest flagship;
• interrupted actions: close the app mid-upload, switch networks, let the battery run low;
• a full phone, with little free storage.

A short checklist

1. Each key screen has a weight budget, and you measure it.
2. Forms save drafts and survive a lost connection.
3. Offline actions are queued and synced, with visible status.
4. Repeated requests never create duplicates.
5. Hosting is chosen with your users’ location and the NDPA in mind.
6. Critical messages have an SMS route.
7. Testing includes slow networks, real devices and interruptions.

Software that respects these conditions feels fast and dependable, and people trust it with their work and their money.