Five Ways Portals Die

I can point to procurement disclosure portals across three continents that launched to press releases and ministerial speeches, then went dark within three years. Honduras's infrastructure portal stopped updating after a government transition in 2022. A West African portal I helped audit shows the same 847 projects it had in 2021. Paraguay's open contracting dashboard redirects to a generic government homepage.

The graveyard is bigger than the survivors.

These failures follow predictable patterns. After a decade building these systems, I've learned to spot warning signs before launch day.

1. The five failure modes

1. The champion leaves.

Every successful portal I've built had one person who made it happen. A permanent secretary who understood data. A minister embarrassed by a corruption scandal. A donor program officer who kept pushing.

When that person transfers, retires, or loses an election, the portal loses protection. I've watched portals go from daily updates to abandoned within weeks of a cabinet reshuffle. The new minister didn't kill it. He just didn't care. That's enough.

2. The pipeline breaks.

Portals don't die from attacks. They die from neglect. A server certificate expires. The person who knew the database password leaves. The procurement system gets upgraded and nobody updates the API connection.

One portal I audited in Southern Africa had published nothing for fourteen months. The team thought the system was working. It wasn't. The ingestion script had been failing silently since a database migration. Nobody was monitoring.

3. The wrong data gets published.

A Central American portal published contract values that were supposed to be confidential during an active bid evaluation. The backlash was immediate. The ministry's response wasn't to fix the filter. It was to stop publishing entirely. Years of work, gone because of one configuration error and a risk-averse reaction.

Publish something embarrassing once, and the institution learns that transparency is dangerous.

4. Nobody uses it.

I've seen portals with complete data and zero users outside the team that built them. No journalists writing stories. No civil society filing complaints. No oversight bodies running queries.

Without external pressure, there's no internal incentive to maintain quality. Data degrades. Updates slow. Eventually someone asks why they're paying for hosting.

5. The donor leaves.

Donor-funded portals face a cliff. For three years, there's budget for servers, developers, training, outreach. Year four, there's nothing. I've seen governments surprised by hosting bills they'd never planned for. The portal wasn't sustainable. It was subsidized.

2. What survivors share

The portals still running after five years share patterns.

They're embedded in process, not added to it.

Uganda's Government Procurement Portal publishes because the e-procurement system feeds it automatically. No extra work for procurement officers. No separate data entry. Complete a procurement, the data publishes. That's why it's still running.

They have domestic funding.

Chile's ChileCompra has survived multiple administrations. The Inter-American Development Bank documented its funding model: transaction fees on the procurement system itself, not donor grants (IDB, 2019). South Korea's KONEPS operates as a government budget line within the Public Procurement Service. When donor funding ends, survivors already have domestic money committed.

They serve someone powerful.

Portals that last serve institutions that can protect them. Audit offices that use portal data to select investigations. Finance ministries that use it for budget monitoring. When the portal helps powerful institutions do their jobs, those institutions fight to keep it running.

They publish data people actually want.

Contract documents. Beneficial ownership. Bid evaluation reports. Survivors publish information that triggers action, not statistics that satisfy reporting requirements.

3. Building for survival

If I were starting a new portal today:

Find the user who'll fight for you. Before writing code, identify who will scream if the portal goes down. An investigative journalist who needs contract data. An auditor tired of requesting documents manually. Interview them. Build for their workflow first. They become your defense.

Automate everything. Every manual step is a failure point. If a human has to upload data, eventually they won't. If someone has to renew certificates manually, eventually they'll forget. Configure automated ingestion from source systems. Set up monitoring that alerts on ingestion failures. Auto-renew certificates. The team should find out about problems before users do.

Plan the funding transition from day one. Don't wait for year three to ask who pays for year four. Build the sustainability model into the project design. Transaction fees. Government budget lines. Cost-sharing across agencies. The conversation is easier before you've built something they depend on.

Make it embarrassing to stop. Once journalists cite your data in stories, once audit reports reference your statistics, once the minister brags about your portal at international conferences, shutting it down has a cost. Build that political cover deliberately. Track media mentions. Document citations in official reports. Create the record that makes abandonment visible.

4. The survival test

Most portal projects focus on capability. Can we publish the data? Can we build the interface? Can we train the team?

The question that matters: Will this still be running in 2030?

If you don't know who pays, who uses it, and who protects it, you're not building a portal. You're building a future 404 page.

I'd rather build something smaller that survives than something impressive that doesn't.