The Offline-First Problem: Why Most Institutional Software Fails in the Field

The most common reason infrastructure software fails in Africa has nothing to do with the software itself. The requirements were wrong. The software was built assuming a condition — persistent, reliable internet connectivity — that does not exist where it is supposed to operate. When the network drops, the software stops working. When the software stops working, the field team reverts to paper. When they revert to paper, the institution reverts to operating blind.

We see this pattern everywhere. A water utility deploys a billing system. The field team is supposed to use it for meter reading, fault reporting, and reconnection orders. The system works well in the operations centre, where there is reliable Wi-Fi. It works badly in Kayole, where GPRS signal fluctuates between one bar and nothing. It does not work at all in Mathare North, where the field technician has to climb a water tower to get signal, and cannot do that while also replacing a burst fitting. After three months, the field team has drifted back to paper. The system is used only by the billing office, which is the least important part of the operation.

This is not a story about bad software. It is a story about a failure to understand the operating environment before writing a line of code.

Zero bars mid-form isn't a failure state here — it's the state the system was built for.

1. An architecture claim, not a failure-rate measurement

This paper argues an architecture decision, not a measured outcome across African institutional software generally. That distinction is stated here before anything else.

What it argues from. Field-deployment logs from two Flux products, AccessWASH and BungeConnect, describing connectivity conditions and sync behaviour in named Nairobi deployment zones — internal, unaudited, and presented as such throughout. A computer-science literature on offline-capable software architecture: local-first software's seven design ideals, developed primarily for personal and creative cloud applications rather than institutional field software;¹ and the consistency/availability trade-off that any system choosing to stay available during a network partition must confront.² Regional and national connectivity statistics from GSMA and Kenya's telecoms regulator, both read directly rather than quoted secondhand.³⁴ One peer-reviewed account, from a different African sector (public-health survey data collection), of the identical failure mode and its mitigation.⁵

What it does not argue from. No controlled comparison of institutional software adoption or data-quality outcomes between offline-first and connectivity-dependent deployments exists in this paper — none was found. No independent audit of the AccessWASH or BungeConnect field data has been conducted; the dead-zone percentages and the adoption-lift claim are Flux's own operational data, not third-party verified. The claim that Kenyan rural base-station power outages correlate with connectivity outages has no source behind it; §5 states it plainly as an unverified mechanism rather than a fact.

What it does not claim. It does not claim offline-first architecture is sufficient, on its own, for an institutional software deployment to succeed — training, procurement, and organisational buy-in are separate and real determinants this paper does not measure. It does not claim a specific share of African institutional software failures trace to connectivity-architecture mismatch specifically, as distinct from other causes; no study measuring that was found, and Appendix B registers the gap. It does not claim connectivity conditions are uniform or static — GSMA's own data shows the regional coverage gap narrowing year over year, which §8 engages as a genuine objection rather than ignores.

What would refute it. Given in full in §10. The sharpest version: if a controlled or large-sample study found online-only institutional software performing as well, on adoption and data completeness, as offline-first software in comparable African periurban or rural deployments, the central architectural claim of this paper would be substantially undermined.

2. What connectivity looks like in the field

The mental model that most software engineers carry about connectivity is shaped by where they work. If you write software in Westlands or Kilimani, your connectivity experience is fast fibre, reliable 4G, and background syncing that happens so fast you forget it is happening. You never think about offline state because you are never offline.

The field technician servicing water connections in the periurban settlements of Nairobi has a different experience. Mobile data coverage in these areas is technically 3G or 4G on the map. In practice, it is intermittent. Coverage maps show spectrum allocation, not real-world signal penetration through concrete walls, corrugated iron, and dense settlement geometry. A phone that shows three bars in an open street shows zero bars in a ground-floor room thirty metres away.

This is not unique to Nairobi's periurban settlements, and it is worth seeing at the regional scale before returning to the specific one. As of 2023, roughly 13% of Sub-Saharan Africa's population lived somewhere a mobile broadband network simply did not reach at all — a coverage gap, measured where the towers are built.³ Layered on top of that is a usage gap: among people who are covered by a network, 60% do not use mobile internet, the highest share of any region GSMA tracks — driven by device cost, digital skills, and affordability rather than signal strength alone.³ Neither figure is a Nairobi-specific or periurban-specific statistic, and neither distinguishes "covered but unreliable" from "covered but unused" — but together they describe a region where the assumption this paper is arguing against (reliable, continuous connectivity) is false for a very large population, not an edge case.

Kenya's own telecoms regulator reports the country ahead of that regional picture on raw scale: 76.7 million mobile (SIM) subscriptions as of June 2025, a 146.3% SIM penetration rate — more active SIMs than people, which mostly reflects multi-SIM ownership rather than universal coverage — and 45.79 million mobile broadband subscriptions.⁴ That report is explicit about what it does not measure: it is supply-side licensee data, not demand-side usage, and it says nothing about field-level signal reliability inside a specific settlement.⁴ National subscription scale and field-level dead zones are different claims, and the table below is evidence for the second, not the first.

Connectivity conditions: AccessWASH deployment zones, Nairobi, 2022–2024. Internal, unaudited.⁶

The data above comes from signal-quality logs recorded by AccessWASH field tablets during normal operations. "Dead zones" are locations where a data operation — syncing a fault report, submitting a meter reading, confirming a reconnection — failed at least once due to connectivity loss. In our densest deployment zones, field staff encountered connectivity failures more than a third of the time. This is Flux's own operational telemetry, from five zones Flux itself chose to deploy in; it has not been independently audited, and it is not a representative sample of Nairobi, let alone Kenya. It is the evidence this paper actually has, and it is presented as exactly that — not as a verified regional statistic.

Software that requires connectivity to function will fail that field technician more than a third of the time, on this evidence. That is not an acceptable failure rate for an operations system.

3. The cost of the wrong architecture

The cost is not just inconvenience. Connectivity-dependent systems create specific failure modes that compound over time.

Data integrity breaks down. When a field technician cannot submit a form because there is no signal, they have two options: wait (which means standing in a client's compound for an indeterminate time) or write it down and enter it later. The second option, which is what everyone actually does, creates a gap between when the event happened and when it entered the system. By the time the meter reading is entered back at the office, the timestamps are wrong. Aggregated data starts reflecting when things were entered, not when they happened. The operations picture the system shows is not the operations picture that exists.

This is not a hypothetical. A 2021 account of mobile-phone data collection during an Expanded Programme on Immunization review across East and Southern African countries reports the identical mechanism in a different sector: "lack of network and internet connection in some locations could not allow some of the surveyors to share the data from the field as they had to wait till when they reach an area with good network which resulted in delays to submit completed questionnaires."⁵ The same paper also reports the mitigation working as designed — forms were "stored securely in the phone until a signal is found and the data is automatically uploaded," and data that could not be sent immediately was sent later once connectivity returned.⁵ That is independent, peer-reviewed confirmation that both halves of this paper's claim are real in practice: connectivity gaps delay submission in African field deployments, and an offline-first, store-and-forward architecture is what keeps that delay from becoming data loss.

Trust in the system erodes. Field teams are rational actors. When a system fails them repeatedly — when they have to re-enter data, when syncing loses work, when the system is unavailable when they need it — they make a reasonable judgment: the paper backup is more reliable. They use the digital system when convenient and paper when not. The institution then has two data streams, neither complete, and no clear way to reconcile them.

The institution stops learning. The whole point of operational software is to give the institution a feedback loop — to let it see the relationship between inputs and outputs, between actions and outcomes. If the data is incomplete or lagged, the feedback loop is broken. The institution cannot learn from what it cannot see accurately.

This is why offline-first is not a nice-to-have feature. It is a prerequisite for data integrity. A system that loses data when offline produces worse operational intelligence than a system that never existed at all — because it creates the illusion of data quality while quietly degrading it.

4. What offline-first actually means

"Offline-first" is sometimes misunderstood to mean "the app still looks like it works when offline." This is cosmetic offline support, and it is useless. Real offline-first means the device is the source of truth, not the server. Reads and writes happen against a local database. The network sync is background infrastructure, not a dependency.

This is not a Flux invention; it names a real, if recent, strand of computer-science architecture. A 2019 paper from Ink & Switch, a research lab, proposes "local-first software" as a set of principles under which the primary, authoritative copy of data lives on the user's own device and servers hold only a secondary copy used to help synchronise across devices — the inverse of how most cloud software is built.¹ Among its seven design ideals is what the authors call "the network is optional": personal computing devices move through areas of varying network availability, and the paper argues software should be designed so a lost connection is an ordinary condition, not an error state.¹ That is the same inversion this paper is describing for institutional field software.

It is worth being precise about where that paper's evidence actually comes from, rather than borrowing its authority uncritically: Kleppmann and colleagues wrote about collaborative creative software — document editors, design tools, note-taking apps — used by individual knowledge workers on laptops and phones in homes, offices, and coffee shops with unreliable but generally recoverable connectivity.¹ They were not writing about institutional field operations in low-connectivity African settlements, multi-user conflict resolution under a shared operational dataset, or the specific failure modes of utility billing and casework systems. The architectural principle — device as source of truth, network as background infrastructure — transfers cleanly. The social and organisational context it was derived from does not, and this paper is borrowing an architecture, not a complete evidence base.

In practice, offline-first means:

Every operation is local first. A fault report is written to local storage the moment the field technician submits it. It does not wait for a server response. It is available immediately on the device. The sync to the server happens whenever connectivity permits — in the background, without blocking the user.

Conflicts are handled deliberately. When multiple technicians update the same record (a shared asset, a shared client account), and those updates were made offline, the system needs a merge strategy. This is not a problem you can defer. You have to design it. The simplest strategies (last-write-wins, server-wins) are often wrong for field operations; a technician who worked on a fault for two hours in a dead zone should not have their work overwritten by a supervisory edit made while they were working.

This is not a design preference so much as a consequence of a well-established trade-off in distributed systems. A system that wants to remain available and keep accepting writes while part of the network is unreachable — exactly what a field tablet in a dead zone needs — cannot simultaneously guarantee that every read reflects the most recent write everywhere. It has to choose, and the influential formalisation of that choice, usually called the CAP trade-off, has been part of the standard literature on large-scale distributed systems since the early 2000s; a widely cited 2009 treatment frames the resulting discipline as "eventual consistency" — replicas are allowed to diverge temporarily and are guaranteed only to converge once communication resumes.² A field system that chooses availability during a dead zone, as this paper argues it should, has implicitly chosen eventual consistency, whether or not its builders ever use that term — and that choice is exactly why conflict resolution cannot be left for later. It has already been decided; it only remains to design the merge logic that makes the decision work.

Sync is resilient. The background sync process needs to handle partial connectivity — uploads that start, pause, and resume without corrupting the data. It needs to queue failed operations and retry them with exponential backoff. It needs to report sync status clearly, so the field team knows which of their records have reached the server and which are still local.

Before, if the internet was bad, we just couldn't work. Now the app works the same whether there is internet or not. We know it will sync when it can. That is all we needed.

— Field supervisor, AccessWASH deployment, Kayole

AccessWASH is built entirely on this architecture. The field tablet writes to a local SQLite database. A background sync process — built on a custom queue with retry logic — handles all server communication. Field staff can complete a full day's work in a connectivity dead zone and sync all of it the next morning when they return to an area with signal. Timestamps reflect when events happened. Data integrity is preserved.

This is not technically complicated. It is architecturally deliberate. You have to decide, before you build anything else, that the device is the source of truth. That decision shapes everything downstream: the data model, the sync protocol, the conflict resolution logic, the test suite. It is much harder to add offline-first to an existing connected architecture than to build offline-first from the start.

5. The same problem in constituency offices

The connectivity problem is not unique to field operations. It appears in a different form in constituency offices — the same institutional-visibility gap this whole body of work is about, one civic layer up from a water meter.

Kenya's constituency offices are not in Westlands. Many are in district towns and sub-county headquarters that have 3G coverage on a good day. Power outages are common in these areas, and it is a plausible, often-repeated claim that they correlate with connectivity outages, since many rural base stations are grid-powered with limited battery backup. I looked for a Kenya-specific source quantifying that correlation and did not find one; it is stated here as a mechanism that is plausible but unverified, not as established fact, and it is flagged again in Appendix B rather than quietly carried as settled. What is not in dispute is simpler: a system that requires connectivity for caseworkers to update constituent records, process bursary applications, or log CDF transactions will break at exactly the moments the office is busiest and the connectivity is worst, for whatever combination of reasons the connectivity is worst.

BungeConnect has the same offline-first architecture as AccessWASH. Caseworkers write to local storage. Records sync when connectivity permits. The system treats connectivity as a transport mechanism, not a dependency.

The result: in offices where we have tracked usage, caseworker engagement with the system is higher during and after connectivity outages than before we deployed. They have learned that the system works when the internet does not. That trust, once established, drives adoption in a way that no training programme can. This, like the AccessWASH table in §2, is Flux's own internal, unaudited observation — a pattern we have seen, not a finding we can point a reader to verify independently.

6. A design principle for African institutional software

If you are building software for African institutions — for water utilities, constituency offices, community health systems, commodity markets, any organisation operating at the level of communities and periurban settlements — here is the constraint that should shape everything:

Assume no connectivity. Build the system to function fully without a network. Then add sync as background infrastructure.

This is the inversion that most software misses. The default assumption in most software architecture is that connectivity exists and offline is the edge case. In much of the operating environment that matters for African institutions, this is exactly backwards. Connectivity is the edge case. Offline is the default.

Build for the default.

— Ken Ruto

7. Objections I take seriously

"Flux has a commercial interest in this conclusion." Flux builds AccessWASH and BungeConnect, and both are marketed in part on their offline-first capability — the central claim of this paper is close to the central claim of Flux's own sales pitch for two of its products. The evidence in §2 and §5 is Flux's own unaudited telemetry and Flux's own field observation, not third-party verified data. I am not going to pretend that is a neutral evidentiary position. The honest mitigation is narrow and partial: the architectural argument in §4 does not depend on AccessWASH or BungeConnect being exemplary products — it rests on a published, peer-reviewed computer-science framework (local-first software) and a well-established distributed-systems trade-off (eventual consistency), both independent of Flux, plus one independent peer-reviewed account from a different sector and different organisation (the EPI mobile data collection study) confirming the same failure mode and mitigation. Those three sources would be true regardless of whether Flux existed. The Nairobi-specific numbers would not be independently checkable even if Flux did not exist to benefit from them, and that is a real limitation of this paper's evidence, not a rhetorical concession.

"Connectivity is improving, and this argument may be time-limited." GSMA's own data shows the Sub-Saharan Africa coverage gap narrowing and infrastructure investment accelerating — new backhaul partnerships, satellite and low-earth-orbit connectivity pilots, and government universal-service-fund reform are all underway as of the 2024 report.³ If coverage gaps close and usage gaps narrow substantially over the coming decade, the population for whom this paper's architecture argument matters shrinks. I think this objection is right as a trend and wrong as a reason to defer the architecture decision today: even a region at 100% coverage will have individual dead zones from terrain, building density, and local infrastructure failure, and the data-integrity argument in §3 does not depend on connectivity being rare — only on it being imperfect somewhere the system needs to operate. But the scale of the population affected, and therefore the urgency of the argument, is a genuinely moving target this paper does not track over time.

"The computer-science literature this paper borrows from was not built for this context." This is correct, and §4 says so directly rather than only in this section: local-first software's seven ideals were developed from research into creative professionals' use of cloud apps, not institutional field operations in low-connectivity African settlements.¹ The architectural principle transfers; the paper's own evidence base for why it matters to that specific population does not. This paper uses the local-first framework for its engineering vocabulary and the eventual-consistency literature for its theoretical grounding, not as evidence that the problem described in §2 is real at the scale claimed — that evidence is Flux's own unaudited data plus one adjacent peer-reviewed study, and no more than that.

"An unverified causal claim about power outages weakens the whole paper." The power-outage/connectivity-outage correlation asserted in §5 has no source behind it. I searched for one specific to Kenya and did not find it. §5 states the mechanism as plausible but unverified rather than as settled fact, and Appendix B registers it as an open citation gap rather than something quietly assumed.

8. Where this architecture argument stops

Offline-first architecture is not sufficient on its own for institutional software adoption to succeed. Training, procurement process, and organisational incentives are separate determinants this paper does not measure.

It does not claim a specific share of institutional software failures in Africa trace to connectivity-architecture mismatch specifically, as opposed to other causes; §1 states plainly that no study measuring this was found.

It does not claim the AccessWASH and BungeConnect field data in §2 and §5 are independently audited or representative of deployments beyond the five named zones and the specific offices tracked; they are Flux's own internal, unaudited operational data.

It does not claim the power-outage/connectivity-outage correlation asserted in §5 is established; it is stated as a plausible, unsourced mechanism.

It does not claim the local-first software and eventual-consistency literatures it draws on were developed for, or validated against, African institutional field deployments; §4 and §7 are explicit that the architecture transfers while the original evidence base does not.

And it does not claim connectivity conditions are static; GSMA's own regional data shows the coverage gap narrowing, and §7 treats that trend as a live, unresolved objection rather than a settled fact in the paper's favour.

9. What would falsify this

Stated as commitments, in decreasing order of how much damage each would do to this paper's claims.

A controlled or large-sample study finds institutional software adoption and data-completeness outcomes are equivalent between offline-first and connectivity-dependent deployments in comparable African periurban or rural settings. That would directly contradict the central architectural claim — that the choice between the two is not neutral — and the right response would be to withdraw the claim, not soften it.

An independent audit of the AccessWASH or BungeConnect field data finds the dead-zone percentages in §2, or the caseworker-engagement pattern in §5, are not representative of the deployments described, or do not hold up under closer examination. That would remove this paper's own primary evidence and leave only the adjacent peer-reviewed study and the general architectural literature — real, but considerably thinner.

A study measuring African institutional software failures at scale finds the dominant cause is something other than connectivity-architecture mismatch — training, procurement timelines, organisational resistance, or staffing, for instance — at a rate that makes connectivity architecture a minor contributor rather than the "most common reason" this paper opens by claiming. That would require the opening claim to be narrowed substantially.

The Kenya-specific power-outage/connectivity-outage correlation asserted in §5 is checked and found false or negligible. That is the narrowest and least damaging of the four: it would require withdrawing one sentence, not the paper's architecture or evidence.

Appendix A — Evidence table

Appendix B — Citation register

CITATION-NEEDED — share of African institutional software failures caused by connectivity-architecture mismatch specifically. Appendix A row 10. The paper's opening claim that this is "the most common reason" is this paper's own position, not a measured finding; no study quantifying the breakdown of causes was found.

CITATION-NEEDED — power outage/connectivity outage correlation, Kenya-specific. Appendix A row 11. Asserted in §5 of earlier versions of this paper without a source; now stated as a plausible, unverified mechanism rather than fact.

CITATION-NEEDED — independent audit of Flux's own field data. Appendix A rows 8 and 9. The dead-zone percentages and the caseworker-engagement claim are Flux's internal, unaudited telemetry and observation; no third party has verified either.