Every few years, a West African government announces a transformational digital platform. A new tax system. A land registry. A single-window investment portal. Press releases go out. Ribbon-cutting ceremonies are scheduled. Sometimes, the platforms actually launch.
Then, quietly, they stop working.
Staff stop using them. The vendor disappears. The government buys something new. The cycle repeats. I've watched it happen across multiple countries, multiple agencies, multiple donor-funded initiatives. And the diagnosis I hear most often is wrong.
" The correlation between corruption, funding, and software longevity is weaker than everyone assumes.
The usual suspects are innocent
When a govtech project fails, the default explanations are corruption or lack of funding. Both are real problems in the region. Neither is the primary cause of the specific failure pattern I'm describing.
I've worked on platforms that were well-funded and honestly procured. They still failed. I've seen underfunded projects with corrupt procurement processes somehow produce tools people actually use a decade later. The actual problem is a systems failure — a collapse of alignment between four things that must move together: procurement structure, user reality, institutional ownership, and technical architecture.
The four failure modes
1. Procurement selects for pitch, not product. Government RFPs reward vendors who can write compelling proposals, not vendors who've built comparable systems before. The evaluation committees often lack technical members. The result: the best storyteller wins, not the best builder.
2. Users are discovered after delivery. I've been called in to 'fix' systems where the vendor conducted zero user research. The platform was designed by engineers who never visited the office that would use it, never observed the actual workflow. Discovery after delivery isn't discovery — it's archaeology.
3. The vendor owns the knowledge. When a platform is delivered as a black box — running on the vendor's servers, documented only in the vendor's head — it's not an asset. It's a dependency. The moment the contract expires, the institution is helpless.
4. Architecture ignores infrastructure reality. A cloud-native, always-online system deployed to an office with 4-hour daily power cuts and 2G data isn't a solution — it's a liability. The technical architecture must be designed around constraint, not best-case assumptions.
What actually fixes it
The good news: every one of these failure modes is addressable. Procurement reform: require demonstrated delivery on similar-scale systems, include a technical evaluator, and stage payments against milestones. Embedded discovery: the build doesn't start until the team has spent real time inside the institution. Deliberate knowledge transfer: build capacity transfer into the contract — source code escrow, documentation a local developer can read, staff trained to a level where they can onboard the next vendor.
" These are not just IT failures. They are governance failures with real human cost.
The cost of inaction
Every failed land registry represents property disputes unresolved. Every broken tax system represents revenue uncollected. Every dead investment platform represents capital that went elsewhere. The pattern is fixable. But it requires decision-makers to care about what happens after the ribbon-cutting. That's where the work begins.