Why many 'tech for good' software projects fail

I lead technology at an NGO working on humanitarian and global development causes. I’m reasonably new to applying software skills in this space, so lately I’ve been trying to read more widely.

Recently I read Tim Unwin’s Digital Inclusion in an Unequal World (ict4d.org.uk), which promptly sent me down a rabbit hole. To further elucidate this dense topic, I gathered a corpus of ICT4D - information and communication technology for development - writing into an archive: github.com/spwoodcock/ict4d-archives, spanning twenty-plus years of reports and field accounts.

I then ran a small LLM-assisted synthesis over the corpus to identify the recurring patterns. What follows are my findings.

On using an LLM for this

Following on from my post on using LLMs ethically, this feels like one of the genuinely good use cases: qualitative synthesis of existing knowledge, in service of ICT4D.

The harms from about 10 minutes of running Opus 4.8 are relatively low, while the upsides - not wasting scarce resources on projects nobody needs, and not building on communities - are high.

I should caveat all of this by saying I’m reasonably new to the sector, so take it with a pinch of salt. But there are some pretty clear patterns worth writing down - and these are by no means novel ideas. A recent scoping review corroborates the findings here, with evidence that common failure modes are much the same as what follows.

A recurring story

Reading about failed projects in the development sector can really fill you with cynicism.

The failures I read about seemed to fall into two broad categories:

  1. Well-intentioned people who either fail to capture what communities truly need or are unable to keep things self-sustaining when their enthusiasm wanes or funding is cut.
  2. Institutional failings, where the whole project isn’t really about serving communities, but the interests of the organisation itself (or its wealthy corporate partners).

The canonical example of the first is the Roundabout PlayPump.

With regard to “tech for good” software, the most important thing I took away is this: working software is rarely the primary challenge.

Five common failures

Most of the following failures are structural to the system and repeat time and time again.

1. Growth over equity

“Tech for good” is often measured by growth: users, downloads, countries worked in, cash transfers.

But the people who most need help are often the least profitable and hardest to reach.

While it’s true that from a utilitarian perspective the most efficient and expedient way to reach as many people as possible can make sense, this systematically missed out the true victims of the global systems that are not designed with a concern for their needs.

2. Institutions captured by whoever pays

Follow the money and you often get to the heart of true motivations.

This is a problem the world over for NGOs. Funders’ priorities best community priorities. When money defines the mission, incentives are not aligned and communities lose out.

3. “Me” over “we”

Awards, keynote speaking, “founders’ stories”, glossy apps, release events, and circle jerking.

The sector tends to reward individuals and institutions, but doesn’t focus as strongly on day-to-day efforts to maintain known and needed technology and efforts to hand over power to the people that actually use the tools.

4. The innovation fetish

Short project cycles plus a bias toward novelty produce a permanent pursuit of the newest thing. Yesterday it was blockchain. Today it’s AI.

Hype outpaces learning, and decades of reports on failed projects go unread. Wilful blindness is a useful tool in the search for new funding, but doesn’t favour well-tested and proven tech.

5. Extraction and dependency

This one is intrinsically linked to a world caught in the grips of surveillance capitalism.

Value - especially data - flows out of communities, often in exchange for something “free”. Dependency flows in: a system only the original vendor can change, risk of enshitification and rising costs, and a soft lock-in that makes a mockery of any open-source licence (open code is not the same as local ownership).

As an example, take UNICEF Giga’s work connecting schools across developing countries. There are some genuine benefits - lower connectivity costs, government leadership, measurable reach - but connectivity is an output, and it’s easily mistaken for an educational outcome. A regional UNICEF case study praises government ownership of the project, while also flagging donor dependency and the need to transition further toward it as a future risk (not to mention government ownership is not the same as community ownership, either).

It’s always worth asking: who ends up owning the infrastructure, the contracts and the connectivity data - and who pays to keep it running once donor support ends?

The path to success

Not everything fails. Some ICT4D systems have run for fifteen or twenty years and genuinely serve their communities.

Specifically for software projects (my main wheelhouse), some tools I’ve had the pleasure to work with have lasted and been used widely: ODK, Ushahidi, CKAN, RapidPro, and CommCare. Generally these projects only sustain if some people find them useful (that isn’t to say that every application of them necessarily improved people’s lives).

Across the wider archive, including the comparison of 19 long-running ICT4D projects, the same patterns recur in their histories, governance, funding, implementation and evaluations. It’s not a guaranteed recipe, but it does give us six useful questions to ask, before you write a line of code:

  1. Solve a real problem. Who experiences the problem, and have they actually asked for it to be solved? Write down how the work happens today, the institution responsible for it, and why an existing tool or a non-digital approach isn’t enough.
  2. Share decision-making power. Who can propose, prioritise, reject, fund and release changes? If the people affected can only offer feedback that we’re free to ignore, we’re consulting them, not sharing power with them.
  3. Fund transitional ownership. Name who will own the data, operations, budget and outcomes. Cost the unglamorous work - hosting, security, support, upgrades and training - and fund it beyond the end of the grant. True community ownership (not neo-colonial lip service).
  4. Design for the people most likely to be excluded. Test with people facing constraints around connectivity, cost, language, literacy or disability, and keep an assisted or non-digital route open. Work out how the data could hurt someone, and who is accountable for consent, correction and appeal.
  5. Measure outcomes, not activity. Before launch, define the change that should follow from the software - not users registered, app installs or data collected. Check who benefits and who remains excluded, and publish the result even if it is null or disappointing.
  6. Reuse before you build. List the tools and previous attempts you investigated, speak to the people who used or maintained them, and explain why adapting one isn’t the answer. If something new is still justified, make sure people can export their data and walk away from it.

A simpler way to think about it

You can boil all of this down to a simple rule:

Build with people, not for them, and never on them. (idea adapted from Tim Unwin, mentioned above)

“For” sounds generous, but it’s usually paternalistic. “On” is what happens when people become test subjects for someone else’s idea. “With” is the only one that survives for the long term - because the community helped decide what gets built, and has a stake in keeping it alive.

A small case study: Ushahidi

After Kenya’s disputed 2007 election, Kenyan developers and bloggers built Ushahidi - Swahili for “testimony” - in a matter of days. People could report violence by web or SMS and see it mapped in near real time. It began with people living through a crisis, using simple technology to solve a problem they had named themselves. Nearly two decades later it is still maintained and used around the world. The reach came later; it was never the point. That origin did not guarantee success: later evaluations also found weak feedback loops, training and coordination. The point is not that Ushahidi was perfect, but that it began with a real problem rather than technology in search of one.

The cheapest improvement available to this whole sector is still the same: stop reinventing the same failure, build on what already works, and start with the people the software is meant to serve.

Postscript: tools I try to build in this spirit

A few tools I’ve been lucky to work on that try to put these ideas into practice:

While I think they both tick some of the boxes, there is definitely room for improvement. They should be held to the same six standards above, and of course, changed or even abandoned if they fail to over time.