Skip to content

Building Software That Survives Kenyan Internet and Power

Kenyan software has to survive two hostile conditions at once: internet that drops and power that fails. Resilience is a set of deliberate design choices, not luck.

By Karani Geoffrey, Founder & CEO, Upeosoft
In short

Software that survives Kenyan conditions is designed for intermittent internet and unreliable power: it works offline and syncs later, resumes cleanly after a device loses power, uses bandwidth sparingly, and never assumes a request will complete. Resilience comes from deliberate engineering choices made at design time, not from hoping the infrastructure holds.

Key takeaways
  • Two failures to design for: internet that drops and power that cuts out, often together.
  • Resilient software works offline and syncs when the connection returns.
  • Operations must be resumable so a sudden power loss does not corrupt data.
  • Low-bandwidth design keeps the app usable on thin or metered connections.
  • Every network call needs timeouts, retries and idempotency to survive flaky links.
  • Resilience is cheaper to design in from the start than to retrofit.

Two hostile conditions at once

Software running in Kenya faces two independent failures that frequently strike together: the internet drops, and the power cuts. A cloud app assumes neither happens. Reality is that a transformer trips, the router dies, and the till loses power - all in the same moment, in the middle of a busy afternoon.

Building software that survives this is not about heroics; it is about assuming failure and designing for it. If the software expects a perfect connection and clean shutdowns, every outage is a crisis. If it expects interruptions, every outage is a shrug.

Surviving the internet dropping

The first pillar is connectivity resilience. The software must keep working when the line goes down, storing what happens locally and syncing it back when the connection returns. Users should barely notice the transition.

That means local-first data capture, a sync layer that queues work and uploads it in order, and conflict handling for when multiple devices changed data while offline. It also means the interface never hangs waiting for a server that is not answering - it degrades gracefully, tells the user what is happening, and carries on with what it can do locally.

Surviving the power cutting out

The second pillar is power resilience, which is subtler. When a device loses power mid-operation, badly designed software can be left in a corrupted state - a sale half-recorded, a file half-written, a database in limbo. The fix is to make operations atomic: they complete fully or not at all, and the system can always recover to a known-good point on restart.

Data has to be written safely so an abrupt shutdown never leaves it inconsistent. Then, when the machine powers back on, the software resumes cleanly and continues syncing whatever was pending. The user restarts and simply keeps going.

Designing for the connections people actually have

Even when there is internet, it is often thin, shared or metered. Software that assumes fast, unlimited data becomes sluggish and expensive on real Kenyan connections.

  • Keep payloads small so screens load on slow links.
  • Sync efficiently - send only what changed, not everything each time.
  • Cache aggressively so common actions do not need the network.
  • Show clear loading and offline states so users are never confused.
  • Be mindful of data cost, since users may be paying per megabyte.

Every network call is a gamble - treat it like one

On a flaky connection, any request to a server, to M-Pesa, or to KRA may hang, fail halfway, or arrive twice. Resilient software treats every network call as unreliable by default.

That means sensible timeouts so the app never waits forever, retries with backoff so a transient failure recovers on its own, and idempotency so a retried request does not double-charge a customer or duplicate an invoice. Pending states are represented honestly rather than optimistically assumed to have succeeded. These habits are what stop flaky infrastructure from turning into corrupted business data.

Software and simple infrastructure together

Great software design carries most of the load, but pairing it with basic infrastructure closes the last gap. A UPS or inverter keeps a critical till alive through a short outage. A mobile data fallback lets the router switch networks when fibre fails. A spare device provides continuity if one dies.

The software should assume none of this exists and still behave correctly - but when it is present, the combination is what keeps a business genuinely uninterrupted. Resilience is a stack: good code first, sensible backups second.

How Upeosoft engineers for resilience

We build for the Kenya that exists, not an idealised one. That means offline-capable applications with robust sync, resumable operations that survive sudden power loss, low-bandwidth design that stays usable on thin connections, and network handling with timeouts, retries and idempotency baked in.

We design this resilience in from the first architecture decision, because it is far cheaper than retrofitting after the outages start costing you. If you want software that keeps your business running when the internet and power do not, talk to Upeosoft and we will build it to survive real conditions.

Frequently asked questions

What is the difference between internet resilience and power resilience?

Internet resilience is about coping when the connection drops - working offline and syncing later. Power resilience is about coping when a device suddenly loses power mid-operation, so data is not corrupted and work is not lost. In Kenya you need both, because an outage often takes down the router and the machine at the same time.

How does software survive a sudden power cut?

By making operations atomic and resumable - meaning a task either completes fully or not at all, and the system can pick up cleanly when it restarts. Local data is written safely so a half-finished transaction does not leave things in a broken state. When the device powers back on, it recovers to a known-good point and continues syncing.

Why does low-bandwidth design matter?

Because many Kenyan connections are thin, metered or shared, and heavy apps that assume fast unlimited data become unusable. Designing for low bandwidth - small payloads, efficient sync, caching, graceful loading - keeps the software responsive on the connections people actually have, and cheaper to run on mobile data.

Do I need special hardware for resilient software?

Good software design does most of the work, but pairing it with basic infrastructure - a UPS or inverter for critical devices, a mobile data fallback for the router - closes the gap. The software should assume neither is guaranteed and behave sensibly regardless, but simple backup power and connectivity make the experience smoother.

Can any software be made resilient?

Resilience is far easier when designed in from the start, because it affects data storage, sync and how operations are structured. Existing software can sometimes be hardened, but deep changes may be needed if it assumed constant internet and power. The best time to build for Kenyan conditions is at the design stage, not after outages start hurting.

Karani Geoffrey
Karani Geoffrey
Founder & CEO, Upeosoft

Karani Geoffrey is the Founder & CEO of Upeosoft, a software and automation company rooted in Kenya. He builds custom software, AI systems, and production-grade ERPNext for businesses across East Africa, and writes about the Kenyan realities - eTIMS, M-Pesa, SHIF, unreliable internet and power - that make or break real systems.

Next step

Want this working in your business?

Upeosoft builds and hardens the systems behind this article - for real Kenyan operations, with eTIMS, M-Pesa and offline realities handled.

Keep reading

Kenyan Compliance and Integrations

Understanding eTIMS: A Plain-Language Guide for Non-Accountants

eTIMS in plain words: it is KRA's way of seeing your invoices as you issue them, so tax reporting is built from real transactions rather than end-of-month guesswork.

6 min readRead article →
Kenyan Compliance and Integrations

SHIF Explained for Employers: What Changed and What to Do

SHIF replaced NHIF as Kenya's mandatory health contribution, and the calculation changed from fixed bands to a percentage of gross pay. Here is what employers must do differently.

5 min readRead article →
Kenyan Compliance and Integrations

The Kenya Data Protection Act: What Every Business Must Know

The Data Protection Act governs how Kenyan businesses collect and use personal data. It is not just for big tech - any business holding customer details has obligations.

6 min readRead article →