Disclosure portals die because governments build them for international donors instead of local contractors and journalists. I track 23 procurement portals across Africa and South Asia that launched to press releases and went completely dark within three years. The survivors share a single, uncompromising trait: they solve a specific, high-stakes problem for a specific local user group. When a portal integrates directly into the daily workflow of a vendor bidding on a $5 million road project, it survives. When it exists solely as a standalone transparency monument to satisfy a World Bank grant requirement, it dies.
The Post-Launch Graveyard
In 2018, I watched a ministry in East Africa launch an infrastructure transparency portal. They spent $120,000 on the software and another $40,000 on the launch event at a luxury hotel. Today, the domain redirects to a sports betting site. This failure follows a predictable pattern. A donor agency mandates transparency. A government hires a consulting firm. The firm builds a dashboard. The dashboard goes live with historical data. Six months later, the project funding ends. The server bills go unpaid. The portal dies.
I see this exact lifecycle repeatedly. Between 2015 and 2022, various ministries across sub-Saharan Africa launched dozens of open data initiatives. The vast majority failed. They fail because project managers treat the portal as the final deliverable. A portal is not a product. It is a window into a data pipeline. When the pipeline requires manual data entry from overworked civil servants, the pipeline dries up.
The Donor Compliance Trap
Failed portals prioritize the wrong audience. Developers build them to display aggregate statistics that look good in donor reports. They feature complex pie charts showing the total volume of infrastructure spending. Local vendors do not care about aggregate pie charts. A local contractor in Kampala wants to know exactly when the Uganda National Roads Authority will release the tender for the Masaka-Mutukula road. A journalist wants to know the exact names of the directors behind the company that won a $10 million bridge contract.
When portals fail to answer these specific questions, users abandon them. Without users, the portal loses its political justification for continued funding. In Nepal, we found that contractors ignored the official government procurement dashboard entirely. Instead, they paid $15 a month to a private SMS service. This service scraped the government's PDF notices and texted them relevant tender alerts. The private service solved a workflow problem. The official dashboard just sat there.
The Anatomy of Survival
Surviving portals flip the priority. They serve the local user first. The best example is the portal built by CoST (the Infrastructure Transparency Initiative) in Honduras. [CITATION NEEDED: Verify exact usage statistics for the Honduras SISOCS portal]. They built the portal, SISOCS, to track public works. It survives because citizens and journalists use it to verify whether a physical road matches the contracted specifications.
To build a survivor, you must adopt the OCDS (Open Contracting Data Standard). OCDS is a standardized data model that ensures procurement data is machine-readable and interoperable across different systems. But adopting OCDS is only step one. Step two requires connecting the portal directly to the government's internal e-procurement system via an API (Application Programming Interface). An API is a software bridge that allows two systems to communicate automatically.
When a procurement officer awards a contract in the internal system, the API updates the public portal instantly. No manual data entry occurs. No civil servant does extra work. In Uganda, the Government Procurement Portal survives because it pulls data directly from the electronic Government Procurement (eGP) system. The portal administrators do not rely on ministries emailing them Excel spreadsheets. The automation guarantees the data stays current. Current data guarantees return traffic.
The Data Quality Baseline
Portals also die when they hide the exact details that matter. A portal showing a $50 million road contract is useless to an investigator without the unit costs. If the portal does not show the price per kilometer of asphalt, the user cannot detect inflation or fraud.
You must publish beneficial ownership data. This means listing the actual human beings who profit from the winning company, not just the corporate shell name. When portals restrict data to high-level summaries, they signal to users that the government is hiding the real transactions. Users recognize this performance instantly and never return.
Counterargument
Critics argue that automation is impossible in low-capacity environments where procurement officers still rely on paper ledgers. They insist that manual data entry portals are a necessary first step to build a culture of transparency before investing in expensive automated systems.
This is false. Manual data entry portals actively destroy the culture of transparency. When you force a procurement officer to do double data entry, once in their internal ledger and again in a public portal, they view transparency as a punishment. They inevitably stop updating the portal. The data goes stale. The public loses trust in the system. If a government lacks digital internal systems, you must digitize the internal workflow first. Building a public portal on top of a paper-based internal system guarantees failure.
The Maintenance Mandate
You must secure the maintenance budget before writing a single line of code. Software rots. APIs break when the underlying systems update. Security certificates expire. I advise governments to allocate 20% of the initial build cost for annual maintenance. If the initial build costs $100,000, you need $20,000 every year to keep it alive.
You must also rank your features by impact. Do not build custom visualization tools. Do not build internal messaging systems. Rank a bulk download feature as your highest priority. Give users a button to download the entire dataset as a CSV (Comma-Separated Values) file. A CSV is a simple text format for database tables that works universally. Data scientists and journalists will build their own visualizations. Your job is to provide the raw material.
What to Do Next
Stop planning your launch event. This week, identify the primary user of your proposed portal. Call three local contractors and two investigative journalists. Ask them to show you exactly how they currently find contract award data. Watch their screens. Document the exact workarounds they use, whether it is paying for SMS alerts or bribing clerks for paper copies.
Your portal must replace their current workaround by being faster and cheaper. If your proposed feature list does not directly eliminate their specific manual task, delete the feature from your scope. Next, secure written confirmation from the IT department that they will provide automated API access to the internal e-procurement database. If they refuse, halt the portal project immediately.
Playbook
Decision Table
| Option | When to Use | Tradeoff |
|---|---|---|
| Adopt immediately | Low-risk process and clear team ownership | Fast progress, limited validation runway |
| Pilot first | Uncertain data quality or mixed institutional capacity | Slower scale-up, higher confidence |
| Defer pending controls | Missing governance, QA, or monitoring guardrails | Lower short-term output, better long-term durability |
Execution Checklist
Failure Modes
- Skipping the section "The Post-Launch Graveyard" during implementation.
- Skipping the section "The Donor Compliance Trap" during implementation.
- Skipping the section "The Anatomy of Survival" during implementation.
Found this useful?
I write about open data systems, transparency, and implementation.
Read more articles →