Earlier this year, during the height of the MPox outbreak, I built a disease tracking system for Sierra Leone. Not a prototype. A working, production-ready system.
It’s disease-agnostic, meaning it can be configured for any outbreak, not just MPox. The architecture is multichannel: USSD, WhatsApp, and a web app. I built it that way deliberately. In Sierra Leone, network connectivity is unreliable. Power cuts are normal. But USSD works on the most basic phones, even with a weak signal. A health worker in the most remote village could submit a case report without needing internet access.
The system aggregates everything and sends automated reports to all stakeholders daily. Real-time dashboards, geographic visualization, trend analysis. The whole thing.
I reached out to someone I knew at the public health office and offered it to them. Free. No strings attached. I just wanted to be an implementing partner. To help.
They said they were interested. We had conversations. And then… nothing.
For a while, I thought I’d done something wrong. Maybe the code wasn’t good enough. Maybe I didn’t explain it well. Maybe I was just some guy with a side project, easy to ignore.
But I’ve since learned this pattern repeats everywhere. And the reasons have almost nothing to do with technology.
The objection that wasn’t really an objection
At one point, I was told their existing system was built in Visual Basic. Mine was in TypeScript. The implication was that this was a barrier.
I offered to teach them. Train the whole team. Stay involved until they were comfortable taking it over completely.
That offer went nowhere too.
The technology gap was real, but it wasn’t the actual problem. It was a reason to say no without saying no.
What I’ve come to understand
Transparency tools threaten people who benefit from opacity.
This isn’t cynicism. It’s documented. Studies on e-governance adoption across developing countries find the same pattern: the technical implementation is rarely the bottleneck. The political economy is.
Think about what a real-time disease tracking system does. It creates accountability. It shows who reported what, when, from where. It makes the data visible to people outside the usual chain of control.
If you’re someone whose position depends on being the gatekeeper of information, that’s not a feature. It’s a threat.
The middleman problem
I’ve seen this in other domains too. Land registration systems that would eliminate the need for brokers who take cuts. Supply chain tracking that would expose “leakage” (a polite word for theft). Permit systems that would remove the discretionary power of clerks who collect informal fees.
The people who benefit from the current system aren’t stupid. They understand exactly what digitization means for them. And they have every incentive to slow it down, request endless “capacity building,” or simply let promising tools die in pilot purgatory.
This isn’t unique to any country. It’s a pattern wherever technology meets entrenched interests.
What I’d do differently
I’m still figuring this out. But a few things are clearer now:
Start with the politics, not the product. Before writing any code, understand who wins and who loses if this thing works. If the losers have more power than the winners, you have a problem no amount of good engineering will solve.
Find the champion who has something to gain. Not just someone who thinks the idea is nice. Someone whose career or reputation improves if it succeeds. Someone with enough power to push it through.
Make the transition gradual. Systems that threaten to replace people overnight get killed. Systems that make existing people look good might survive.
Accept that some contexts aren’t ready. This is the hard one. Sometimes the honest answer is that the conditions for adoption don’t exist, and no amount of outreach or training will change that.
I still build anyway
I could tell you I’ve figured it out. I haven’t.
I still build tools for contexts where adoption is uncertain. The MPox tracker is still live. I’ve built land registration prototypes, health systems, civic tools. Some have been used. Many haven’t.
But I’ve stopped thinking of unused tools as failures. They’re prototypes for a future that might not be ready yet. And every one teaches me something about the gap between what’s technically possible and what’s institutionally achievable.
The last mile isn’t technical. It’s trust. It’s incentives. It’s power.
And sometimes, it’s just waiting for the right moment.
Loading comments...