Africa's Institutions Don't Have a Funding Problem

In 2019, I stood inside the operations room of a water utility serving roughly 200,000 people in a mid-sized Kenyan city. The walls were covered in hand-drawn maps — laminated printouts annotated with years of corrections in different colours of pen, each layer representing a new technician's attempt to reconcile what was on paper with what actually existed underground. A whiteboard held the day's fault reports, written in a format that hadn't changed in fifteen years. The billing office next door had three computers, two of which worked, running software so old that the vendor had ceased operations before I finished primary school.

This utility was not poorly managed. The people running it were experienced, dedicated, and deeply knowledgeable about their network. They had survived budget cuts, political interference, and the particular chaos of Kenya's devolution process. They had kept water flowing to most of their customers most of the time, which is harder than it sounds.

What they did not have was tools.

Not a single field technician had a smartphone app to log a fault. Meter readers recorded readings on paper forms that took two weeks to reach the billing office. Customer complaints came in by phone and were written into a notebook. The utility had no real-time view of how much water it was producing versus how much it was billing for. It was operating, effectively, blind. I would later come to call this the missing layer: the absence of an operational data infrastructure that lets an institution see what it is actually doing.

I had come to study this utility as part of research I was conducting on water service providers across Kenya. What I found over the following months, as I visited utility after utility, was not an anomaly. It was the norm.

1. What this paper is built on, and the test that would break it

Before making the argument, it is worth being precise about what kind of claim this is.

What it argues from. My own fieldwork across water utilities in Kenya since 2019, including the opening account above and the "45 utilities" figure in §2 — my own documented experience, not an independently audited survey. Flux's own account of its AccessWASH and BungeConnect deployments, described in §4, relabeled here as internal and unaudited rather than independently verified outcomes. Kenya's water-sector regulator's own current published performance data.¹ A World Bank field-experiment paper using a Nairobi utility's own administrative billing data.² The United Nations' own population projections.³ A peer-reviewed framework for why information systems fail when transplanted across institutional contexts.⁴

What it does not argue from. No independent audit exists of the Flux Water or BungeConnect outcomes described in §4. No randomized or quasi-experimental study isolates "giving an institution appropriately translated software tools" as a treatment and measures the effect against a comparison group. The claim that water-vendor prices in Nairobi's informal settlements run many times higher than formal utility rates is well-documented across multiple sources, but the sources disagree sharply on the exact multiple, and this paper does not resolve that disagreement — it states the range rather than picking a number.⁵

What it does not claim. It does not claim technology is sufficient on its own; §9 is explicit, and a serious outside argument that technology without existing institutional capacity and intent merely amplifies whatever is already there — including dysfunction — is engaged directly in §8 rather than ignored.⁶ It does not claim corruption or underfunding are not real; §9 names both directly. It does not claim the AccessWASH and BungeConnect numbers in §4 have been independently measured.

What would refute it. Given in full in §11. The sharpest version: if institutions given appropriately translated operational software show no measurable improvement relative to comparable institutions that are not, once that comparison is made independently of Flux's own reporting, this paper's central practical claim fails.

2. The Argument Everyone Gets Wrong

When people talk about why Africa's public services underperform — why water utilities lose a large share of the water they produce,¹ why constituency offices fail to track the cases they're handling, why community health workers' data never makes it to the Ministry of Health — they reach for familiar explanations. Corruption. Underfunding. Weak institutions. Colonial legacies.

These are real. I am not dismissing them.

But they are not the whole story. And they are, in an important sense, not the most actionable part of the story.

Here is what I have come to believe, after building software for African water utilities since 2019, after studying utilities across Kenya, after sitting in constituency offices and watching MPs try to manage thousands of constituent cases through WhatsApp: Africa's public institutions are not failing primarily because they are corrupt or underfunded. They are failing because they are operating without the tools to do their jobs.

This is a different diagnosis. And it points toward a different treatment.

The water utility in that Kenyan city wasn't losing a large share of its water because its staff were stealing it — most of those losses were commercial: unmetered connections, billing errors, meter reading gaps that compounded over months. Problems that software solves, at least in part. The constituency office drowning in a WhatsApp backlog wasn't staffed by incompetent people — it was staffed by capable people with no case management system, no constituent database, no way to track whether a problem had been resolved. Problems that software solves, at least in part.

The tools that would fix these problems are not exotic. They are not experimental. They exist today, running inside municipal systems in Amsterdam and Singapore and São Paulo. They have been refined over decades. They work — there, for those institutions, under those conditions.

What does not exist — what has not existed, until very recently — is a version of those tools built for here.

3. The Translation Problem

Built for M-Pesa, not Stripe. Built for GPRS connectivity in a rural ward, not fibre in a data centre. Built for a utility manager who came up through the field and learned software on a feature phone, not a product manager in San Francisco with a computer science degree. Built for the specific, messy, human reality of a Kenyan constituency office in 2025, not an idealised workflow diagram drawn up in a development finance institution's headquarters.

This is what I mean by translation.

The mistake that well-resourced organisations — development banks, international NGOs, even some local tech companies — make is to assume that the existence of a global software solution means the problem is solved. It is not. A water utility management system built for a European context will fail in Nakuru not because Nakuru's utility staff are less capable, but because the assumptions baked into that software — about connectivity, about user literacy, about payment infrastructure, about the specific data standards used, about which workflows are automated and which require human judgment — are wrong for Nakuru.

Wrong assumptions produce software that doesn't get used. Software that doesn't get used produces utilities that keep operating on whiteboards and laminated maps.

I have watched this happen. An international NGO partners with a global software company to deploy a management system for a network of rural water utilities. The software is technically excellent. The NGO funds a training programme. The system goes live. Two years later, during a follow-up visit, the system is running on one computer in the corner of the office. The rest of the staff have gone back to their spreadsheets — not because they are resistant to technology, but because the software assumed workflows that don't match how their organisation actually operates, because it requires an internet connection they can't always guarantee, because the support documentation is in English and the interface doesn't accommodate the local fee structures they use.

The problem was not the technology. The problem was that nobody did the translation work. There is a peer-reviewed name for the gap between what a system assumes and what an institution actually has — a "design-actuality gap" spanning information, technology, processes, objectives, staffing, management structures, and other resources — and the wider that gap, the more likely the deployment fails outright or survives only as a shell nobody uses.⁴ The donor-funded system in the story above did not fail for lack of budget or good intentions. It failed because nobody closed that gap before shipping it.

4. What I Have Seen When the Translation Gets Done Right

In 2019, I founded Flux Water — a platform built from the ground up for Kenyan water utilities. Everything was designed around the specific operational reality of how these utilities actually work: how field technicians move, what connectivity they can rely on, how customers pay (primarily M-Pesa), what data the utility actually has versus what it theoretically should have.

By 2023, on Flux's own account, four major Nairobi utilities were running on the platform, field operation costs had dropped by 90%, and the company had built what it describes as Kenya's largest water utility dataset — 30 million data points — plus a claimed United Nations recognition during a Global Handwashing Day response that no public UN record corroborates. That paragraph is Flux's own description of its own product, not an outcome independently measured or audited by anyone outside the company. Not because we invented anything new, but because — on this same unaudited account — we translated something that already existed into something that actually worked here.

Not because we invented anything new. Because we translated something that already existed into something that actually worked here.

Then, in 2024, I started watching a different kind of institution struggle with the same problem.

Kenya's 290 constituency offices — the front line of devolved government, the places where ordinary Kenyans go when they need help — were drowning. MPs were managing constituent cases through personal WhatsApp numbers. Caseworkers were keeping records in exercise books. CDF allocations were being tracked in Excel spreadsheets shared over WhatsApp groups. Bursary applications were arriving on paper, being evaluated by gut feel, and being lost in filing cabinets.

Again: not because the people running these offices were incompetent. Because nobody had built them tools.

BungeConnect — the operating system for Kenya's parliamentary offices — launched in 2024. Constituency case management, constituent databases, CDF tracking, SMS broadcasting. The same thesis, a different institution, and the same caveat: these are Flux's own, unaudited deployment claims, not independently measured outcomes.

Two products. The same insight underneath both of them — and the same open question, named honestly here rather than only in the appendix: nobody outside Flux has yet measured whether either one actually moves the needle at the scale this paper's broader argument needs.

5. The Larger Pattern

The more I have studied this, the more I have come to see it as a pattern that extends across every sector delivering basic services in Africa.

Water utilities running on paper. Constituency offices running on WhatsApp. Community health workers reporting on paper forms. Rural financial cooperatives — SACCOs, chamas, village savings groups — managing billions of shillings of community capital in exercise books and mobile money logs that nobody can analyse in aggregate. Small energy utilities operating mini-grids without the operational data to price their services correctly or predict demand.

In every case, the problem is not the absence of technology in the world. It is the absence of technology that has been properly translated for these specific institutions, in these specific contexts, with the specific constraints and capabilities they actually have.

This is the gap that FluxImpact exists to close.

A Nairobi utility's own administrative billing data, examined independently by World Bank researchers running a field experiment rather than reported by the utility's own marketing, illustrates the same pattern from a different angle. Between 2014 and 2018, after Nairobi's utility connected 137,000 previously unconnected residents of informal settlements to piped water, the share of bills and loan repayments actually collected fell from above 65% to below 50%, and the share of compounds reporting having received water in the past week fell from 95% to 40%.² That is not a story about a corrupt utility, or even primarily an underfunded one — the connections themselves had already been subsidised and financed. It is, in significant part, an operational-visibility and revenue-collection story: the utility had expanded its network faster than its ability to track, bill, and follow up on what it had built. The two interventions the researchers actually tested — face-to-face engagement with customers, and systematic contract enforcement for nonpayment — are themselves administrative tools, not funding or anti-corruption measures, and the enforcement approach measurably increased payment without the negative side-effects (reduced service, reduced trust, tenant displacement) the utility had worried about.² This is closer to a controlled test of this paper's thesis than almost any other evidence in this paper, and it is worth being honest that the thesis survived it in a narrower form than the opening anecdotes suggest: the tool that worked was not visibility alone, but a specific administrative process — contract enforcement — built on top of it.

6. What We Are Doing About It

FluxImpact is a research and technology lab. The research part is not incidental — it is the foundation. We do not build software for an institution before we understand, in granular detail, how that institution actually operates: what its workflows are, what data it has and doesn't have, what its staff can and cannot do, what its users expect, what its connectivity looks like, how it handles money, who makes decisions and how.

This research produces something useful in its own right: evidence. Data about how Kenya's public institutions are actually performing, where the operational gaps are, what interventions have worked and what hasn't. We publish this research — as essays, white papers, policy memos — because the evidence is a public good even before a single line of software is written.

Then we build. Software and hardware, bespoke to the institution, translated for the context. Sometimes this becomes a FluxImpact product — a platform that can be deployed across many similar institutions. Sometimes it is commissioned work for a specific partner. Always it is built to be owned and operated by the institution itself, not dependent on our continued involvement to function.

Then we measure. We track outcomes against baselines established in the research phase. We publish what we find, including what didn't work, because the field learns faster when failures are documented as carefully as successes. This paper's own §4 and §5, and Appendix B, are an attempt to hold that standard against this paper's own claims, not only against the subjects it studies.

7. Why This Matters Beyond Efficiency

I want to be careful here, because it is easy to make this argument sound like a technocratic pitch — as if better software is simply more efficient, and efficiency is the point.

It is not just about efficiency.

Residents of Nairobi's informal settlements without a direct utility connection have been reported, across several independent sources, to pay substantially more per litre for water bought from vendors and kiosks than residents with a formal connection pay through their utility bill — reports disagree sharply on the exact multiple, ranging from roughly four times to, at the extreme end of small-quantity kiosk pricing, closer to twenty times the utility's bulk rate, which is itself evidence that nobody has a single clean number for this, only a consistent direction and a wide, context-dependent order of magnitude.⁵ Part of why utilities haven't extended their networks into these areas, and part of why the networks they have extended under-collect once built (§5), is that they don't have the operational capacity to manage a larger network — they can't track what they'd be deploying, bill for it, maintain it, or respond when something goes wrong. The software problem produces an equity problem. Fixing the software problem is a precondition for an equity intervention, though — on the Nairobi evidence in §5 — not a sufficient one by itself.

In Kenya's constituencies, CDF allocations — public money intended for public goods — are distributed with limited public accountability over how specific projects are chosen or whether funds reach their intended use. The software problem produces a democracy problem.

In Kenya's financial system, millions of people who are highly financially active — who save in chamas, borrow from SACCOs, pay utility bills via M-Pesa — are invisible to the formal financial system because their financial activity runs through informal rails that generate no structured data. The software problem produces an inclusion problem.

In each case, better institutional software is not just an operational improvement. It is, on this paper's argument, a precondition for the kind of accountability, equity, and inclusion that African societies are owed — a precondition, not, as §5's own evidence shows, a guarantee.

8. Objections I take seriously

"Flux has a commercial interest in this conclusion." Flux builds AccessWASH, BungeConnect, and the research programme FluxImpact runs; this paper's central argument is close to being the founding thesis of Flux's own business. I am not going to pretend the incentive to believe it isn't there. The honest mitigation is partial: the WASREB sector data in §2, the UN population projection in §9, and the Coville et al. Nairobi findings in §5 are all independent of Flux and would show the same thing whether or not Flux existed. What is not independent is the leap from "the translation thesis is plausible and supported by independent evidence elsewhere" to "AccessWASH and BungeConnect, specifically, are doing this well" — §4's own numbers on those two products are Flux's unaudited account of itself.

"Technology amplifies whatever is already there — including dysfunction — rather than fixing it." This is a serious, well-known critique of the entire genre of argument this paper makes. Kentaro Toyama's "law of amplification," developed from years running Microsoft Research's technology-for-development lab in India, holds that technology's primary effect is to amplify existing human and institutional capacity and intent, for better or worse — so that a competent, well-intentioned institution gets more capable with better tools, while a dysfunctional one simply fails faster or at greater scale.⁶ This paper's own opening example — a water utility with experienced, dedicated staff that had merely never been given tools — is exactly the case Toyama's framework predicts technology should help. But the framework cuts the other way for an institution where the missing ingredient is not tools but intent: a constituency office where CDF is used as a patronage instrument, to take an example this paper names directly in §9, is not a case this paper's thesis can rescue by handing it better case-management software, and claiming otherwise would be a form of the exact solutionism Toyama is arguing against.

"The Coville et al. findings complicate the thesis more than they support it." A fair reading of §5. The Nairobi utility's own revenue-collection crisis after the 2014 informal-settlement expansion is evidence that visibility alone did not prevent the underlying problem — the connections existed and were tracked well enough that the World Bank researchers could run the study at all, using the utility's own administrative billing data, yet collection still collapsed. What ultimately worked, in that controlled study, was not more visibility but a specific enforcement process built on top of existing administrative data. This paper's broader "give institutions tools" framing is less precise than "give institutions the specific administrative tools and processes that correspond to their actual failure point," and §5 is where that precision is forced rather than assumed.

9. What I Am Not Saying

I am not saying technology solves everything. It does not.

Corruption is real and software does not cure it — though software that creates data transparency makes some forms of corruption significantly harder to conceal.

Underfunding is real. A utility that cannot pay its staff or maintain its infrastructure will not be saved by a management platform.

Political interference is real. A constituency office where the MP uses CDF as a personal patronage tool will not be transformed by case management software, and §8 is explicit that this is precisely the case Toyama's amplification critique predicts this paper's thesis cannot rescue.

I am saying something more limited and, I think, more honest: that across Africa's public institutions, there is a layer of operational failure that is attributable to the absence of appropriate tools, that this layer of failure is large and documentable even if its exact size is not something this paper has measured, and that fixing it is tractable in a way that fixing corruption or chronic underfunding is not. That fixing it will not solve everything, but it will make a significant and measurable difference to the lives of the people these institutions are supposed to serve, for the subset of institutions where capacity and intent already exist and tools are the actual constraint.

And that somebody has to do the translation work, for each institution in turn, rather than assuming a generic platform will do it.

10. The Next Billion

Kenya's population will roughly double in the coming decades, and Africa's population is projected by the United Nations to reach roughly 2.5 billion by 2050.³ The institutions that are supposed to deliver water, healthcare, democratic representation, and financial services to this growing population are, right now, running on exercise books and laminated maps, in the cases this paper has documented directly.

This is not inevitable. The technology that could equip these institutions exists. The evidence of what works — and what doesn't — can be built up and published, so that the whole field learns faster, including this paper's own field: §4, §5, and Appendix B name what Flux's own products have not yet proven, rather than only what the broader thesis claims. The translation work, though hard and specific and slow, can be done.

That is what FluxImpact is for.

The technology exists. Africa's institutions deserve to have it — and deserve an honest account of how much of it has actually been proven to work, which is a standard this paper has tried to hold itself to rather than only asking of others.

Ken Ruto is the Principal Lead of FluxImpact, a research and technology lab based in Nairobi, Kenya. He is the founder of AccessWASH and BungeConnect. He can be reached at kkimtai@gmail.com or at kenruto.fluximpact.org.

11. What would falsify this

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

Institutions given appropriately translated operational software, measured independently of Flux's own reporting, show no improvement relative to comparable institutions that do not receive it. That would directly contradict this paper's central practical claim regardless of how well the translation argument reads, and the right response would be withdrawal, not a softer restatement.

An independent audit of AccessWASH's or BungeConnect's own claimed outcomes (§4, §5) finds the actual effect was materially smaller than, or absent relative to, what Flux has reported. That would not disprove the broader translation thesis, which has independent support elsewhere in this paper, but it would require withdrawing this paper's own two central illustrations of it.

A well-resourced institution, given modern, well-translated software and demonstrated staff willingness to use it, is shown to perform no better than before. That would suggest Toyama's amplification critique in §8 is closer to the whole truth than this paper's thesis, and that tools are not actually the binding constraint even in the favourable case this paper's thesis is built around.

A large-scale study finds that corruption or underfunding, rather than missing tooling, accounts for most of the variance in African public-institution performance once tooling is held constant. That would not make the translation argument false, but it would substantially shrink the size of the problem this paper claims tooling actually explains.

Appendix A — Evidence table

Appendix B — Citation register

CITATION-NEEDED — independent measurement of AccessWASH's and BungeConnect's actual outcomes. Appendix A rows 7–9. No audit independent of Flux was found for either product's claimed deployment numbers.

CITATION-NEEDED — the UN Global Handwashing Day recognition claimed for Flux Water. Appendix A row 7. No public UN record corroborating this specific claim was found in this pass; it is carried forward as Flux's own account, not verified.

CITATION-NEEDED — the variance in institutional performance attributable to tooling versus corruption or underfunding. Appendix A row 10. No study decomposing this was found; this paper's claim that tooling explains "a large, documentable" share of the failure is argued from accumulated case observation, not measured.