Every infrastructure disclosure portal I have worked on across Africa and South Asia that launched to a press release went dark within three years. The failures follow predictable patterns: they rely on manual data entry, they treat contract award as the finish line, and they build for politicians instead of practitioners. Portals that survive automate data extraction directly from government systems and use OC4IDS to connect procurement data to physical project delivery. If you want your infrastructure transparency portal to outlast its launch funding, you must hardwire it into existing administrative workflows.
1. Manual Entry Guarantees Failure
Every manual-entry portal I observed was eventually abandoned. When governments build platforms that require procurement officers to log in and upload spreadsheets, compliance drops to zero the moment project funding ends. Across five implementations in Uganda and the wider East Africa region, we found a stark divide. Portals that relied on human memory and goodwill died. Portals that pulled data automatically via APIs survived.
The logic is absolute: transparency cannot be a separate, additional task. It must be a byproduct of doing the work. You extract data from the e-GP system and the IFMIS. When a procurement officer issues a tender, that action must automatically populate the public portal. In our fieldwork we saw donor-funded projects hire teams of data entry clerks to backfill portal data. The day the grant closed, the portal died. Survivors eliminate the data entry clerk entirely.
2. Procurement Is Not the Project
Portals die when they answer the wrong questions. Citizens do not care who won a contract; they care whether the hospital has a roof. Many failed portals use OCDS as their only framework. OCDS is powerful for procurement transparency, but it stops at contract award. OC4IDS extends beyond that point, linking procurement records to physical delivery milestones, cost variations, and completion status. Portals built on OC4IDS alone give users a continuous project narrative. Portals built on OCDS alone give users a receipt.
In three countries where I have directly supported implementation, the portals that retained active users were the ones where an engineer or community monitor could open the system and see whether last month's progress payment matched last month's reported construction output. That comparison is only possible when the OCDS procurement layer and the OC4IDS infrastructure layer are both present and linked.
3. Assurance Gives the Data Teeth
Here is the counterargument I hear most often: if you automate disclosure and publish everything, accountability follows automatically. It does not. Raw data published without verification attracts no one. Governments can populate a portal with optimistic figures and face no consequence.
The CoST Independent Review mechanism exists precisely to close this gap. An independent reviewer, commissioned by a Multi-Stakeholder Group that includes government, industry, and civil society, periodically examines disclosed project data and flags discrepancies between what was promised and what was delivered. In Uganda, Independent Reviews have surfaced cost overruns and scope changes that were buried in routine progress reports. The portal becomes credible not because the data is published, but because someone with authority checks it and publishes the findings. Without that assurance layer, a disclosure portal is a filing cabinet. With it, it becomes an accountability instrument.
4. Build for the Practitioner, Not the Press Release
The portals I have watched survive longest were not the most visually impressive at launch. They were the ones designed around a specific user doing a specific job: a district engineer tracking payment schedules, a civil society monitor comparing tender prices against market rates, a journalist looking for projects that received full payment but show no physical progress.
Portals built for ministerial launches optimise for aesthetics. Portals built for practitioners optimise for data quality, search functionality, and downloadable datasets in machine-readable formats. The OC4IDS schema supports exactly this kind of practitioner use because it structures data consistently across projects, making comparison and analysis possible without specialist technical skills.
5. Sustainability Is a Technical Architecture Decision
Most portal sustainability conversations focus on political commitment or funding continuity. Both matter, but the more durable lever is technical architecture. A portal that requires a dedicated team to maintain custom integrations will collapse when that team disperses. A portal built on standard IFMIS integration points, standard OC4IDS schema, and documented API connections can be maintained by the government's existing IT staff long after external support ends.
In my experience across East Africa and South Asia, the single strongest predictor of a portal surviving beyond its initial funding cycle is whether the data pipeline runs without human intervention on the government side. If it does, the portal persists even when political enthusiasm fades. If it does not, no amount of donor funding or ministerial commitment will save it.
The Next Step
If you are planning an infrastructure transparency portal, commission a technical audit of your e-GP and IFMIS systems before you write a single line of portal code. Map every data field you intend to publish against an OC4IDS schema and identify which fields can be extracted automatically and which require manual input. Eliminate every manual input you can. Then design your Independent Review process before your launch date, not after. The portal is the pipe. Assurance is what makes the water safe to drink.
Found this useful?
I write about open data systems, transparency, and implementation.
Read more articles →