Our reasoning

Why we think this works — and how we could be wrong.

The bet Digital Missions is making, stated plainly enough to be checked against what happens.

The bet

Our bet is that the failure rate of government digital systems in West Africa is mostly an implementation-and-sustainment problem, and that both can be fixed.

We do not claim that nobody else builds these systems. Donor financing for digital government is large and will be spent whether or not we exist. We claim something narrower and more testable: that the share of these projects that survives contact with reality can be moved, and that moving it is the most valuable thing our particular team can do.

This page sets out that reasoning using three questions funders ask of any intervention — how important is the problem, how tractable is it, and how neglected — followed by the question that matters most: what would happen without us.

Three questions

Importance. Tractability. Neglectedness.

01 / Importance

The systems touch everyone.

Roughly 800 million people worldwide have no official proof of identity; many are children whose births were never registered, and most live in Sub-Saharan Africa and South Asia (World Bank ID4D Global Dataset, 2025). Identity, registries, and data exchange are the layer every other public service depends on. The best evidence that this layer changes outcomes comes from India: when Andhra Pradesh randomized biometric smartcard payments across 157 sub-districts and 19 million people, payments arrived faster, leakage fell, and the time saved by recipients alone paid for the intervention (Muralidharan, Niehaus, and Sukhtankar, American Economic Review, 2016). The same authors later found that stricter biometric verification in Jharkhand’s food-ration system excluded eligible households while delivering much smaller gains against leakage (Muralidharan, Niehaus, and Sukhtankar, 2020). Identity systems can fail by working. We treat the first result as evidence of what is possible and the second as a warning about how it is done; neither is a guarantee that it transfers.

02 / Tractability

Hard, and harder if you fly in.

Institutional change has low base rates everywhere, and lower still where budgets are tight and turnover is high. We do not pretend otherwise. The most rigorous account of why is Andrews, Pritchett, and Woolcock’s Building State Capability (2017): governments — often rewarded by donors for doing so — adopt systems that look capable, what the authors call isomorphic mimicry, and lean on them before the capability to run them exists, what they call premature load bearing. Their answer, problem-driven iterative adaptation, builds capability in context, one concrete problem at a time. Our recce-then-embed model is that approach applied to digital infrastructure. The recce is a gate precisely because some missions cannot be made to work, and we would rather decline than add to the failure statistics.

03 / Neglectedness

The money is not scarce. Implementation that outlasts the contract is.

Digital development is well funded, and implementers are not rare. What is thin is implementation a ministry still runs once the contract ends. Ghana’s hospital records system, LHIMS, ran for eight years and went dark in 2025 after its contract lapsed and the ministry and the vendor fell out over payment and over who controlled the system and its data: the build had succeeded; the handover never happened. We believe — and have not yet demonstrated — that this implementation-and-sustainment layer is the binding constraint. Demonstrating it is part of the work.

What happens without us

The money gets spent either way. Our value is the difference.

If Digital Missions did not exist, the same programs would be procured and another implementer would deliver them. Our value is not the whole system; it is the gap between what that outcome would have been and what ours is. We expect most of that gap to come not from whether a system is built, but from whether it is still running, under the state’s control, five years after handover.

Three outcomes

Where we think our value sits.

  1. 01 The system is built and survives either way.

    Our value is close to zero. This will be true for some missions, and we will say so when it is.

  2. 02 The system is built but does not survive handover.

    Our value is its durability: operators trained, workflows owned by the state, recurrent costs planned for. We expect this to be where most of our value lies.

  3. 03 The system never works.

    Our value is the full outcome. Heeks’s estimate puts outright failure at around a third of projects, so we do not expect this case to be rare in general. We expect it to be less common among missions that pass a recce, and we will report the actual share.

What we will measure

Every mission brief states its conditions of success before work begins. Every mission report publishes what was predicted against what happened. The annual transparency report includes the missions that did not work, and why.

Each mission brief also states the base rate we are measuring against — the donor’s own outcome record for comparable projects in the same country where it exists, sector figures where it does not — and each mission report publishes our result beside it. Without that comparison, none of the measures below can tell our value from the default implementer’s. The recce selects missions we believe can work, which will flatter the comparison, and we will say so. Where the comparison shows no gap, we will say that too.

The measures we hold ourselves to are outcomes, not activity:

  • People reachable through the system
  • Services live, with real usage — not launch counts
  • Time from request to service, before and after
  • Cost per person reached
  • Share of day-to-day operation under state control at handover, twelve months later, and at three and five years — published whether or not we are still engaged
  • Recurrent cost funded in the partner’s own budget
How we could be wrong

Five ways the bet fails.

  1. 01 The binding constraint is recurrent financing, not implementation.

    If systems die of unpaid bills regardless of how well they are built, an implementation partner does not fix the problem. We treat recurrent financing as part of every mission brief, and we will report on whether that is enough.

  2. 02 Embedded teams do not survive political transitions either.

    Elections and cabinet changes may wash out institutional memory faster than we can build it. Our five-year durability claim is the one we are least able to evidence today.

  3. 03 The evidence does not transfer.

    The strongest results come from India, with a stronger state and different administrative traditions. West Africa may respond differently, and we should expect smaller effects.

  4. 04 We become one more vendor.

    The pressures that turn implementation partners into software vendors are real. Our red lines and capability-transfer requirements are designed against this, but design is not proof.

  5. 05 The system works and excludes people.

    Biometric verification can deny people who are entitled, as it did in Jharkhand. Every system we build keeps a manual path for the people the technology fails, and we measure exclusion alongside leakage.

The benchmark

A serious funder will ask whether the same money would do more given directly to poor households as cash. We take the question seriously. Our answer is that foundational infrastructure is a different kind of bet: a low probability of success on any single mission, and compounding value when it holds, because every later service runs on it.

That answer is only respectable if we measure. If, over a reasonable horizon, our outcomes do not support it, we will say so in the transparency report.

Sources

  1. Heeks, R. (2003). Most eGovernment-for-Development Projects Fail: How Can Risks be Reduced? iGovernment Working Paper 14. Institute for Development Policy and Management, University of Manchester.
  2. Muralidharan, K., Niehaus, P., & Sukhtankar, S. (2016). Building State Capacity: Evidence from Biometric Smartcards in India. American Economic Review, 106(10), 2895–2929.
  3. Muralidharan, K., Niehaus, P., & Sukhtankar, S. (2020). Identity Verification Standards in Welfare Programs: Experimental Evidence from India. NBER Working Paper 26744.
  4. Andrews, M., Pritchett, L., & Woolcock, M. (2017). Building State Capability: Evidence, Analysis, Action. Oxford University Press. Open access.
  5. World Bank (2025). Identification for Development (ID4D) Global Dataset 2025.
  6. The framing of importance, tractability, neglectedness, and counterfactual impact follows the questions set out in MacAskill, W. (2015). Doing Good Better.
What we will not build →