Insight: The Vendor Behind the State
On a debarment, a decade-old handover agreement, and the difference between owning a system and being handed one.
This year, a global development lender debarred a vendor and its chief executive for at least five years after finding them responsible for fraudulent and obstructive practices in a donor-funded digitization project.
A private contractor built a flagship citizen services platform with donor funding, then transferred it to the state “completely and unconditionally,” making the state the new owner of the digital infrastructure.
Yet years later, a government audit found that the state still lacked full operational control. Because most government services now ran through the platform, the audit warned bluntly that the vendor’s control created a single point of failure for the state.
This is not a technology problem but an institutional one—and a strikingly common one. Across the continent, the same pattern appears wherever a single digital platform underpins a public service, from revenue systems, registries, and information platforms to new portals emerging as similar vendor arrangements spread across markets and sectors. A private vendor becomes so embedded in service delivery that the government, despite nominally owning the system, cannot run or audit it—or replace the vendor—without disrupting the people who rely on it.
Once a vendor becomes essential to service delivery, procurement is no longer just about price and technical capability. It becomes a test of institutional resilience: can the state actually walk away when necessary, rather than merely claim that right in the contract?
Our five-pillar framework is built to prevent exactly this kind of failure.
BAROS applies the same five stages to every engagement, regardless of sector: BUILD, AMPLIFY, RESOLVE, OWN, and SUSTAIN. Each tests a different aspect of the partnership. BUILD examines whether the right foundations are in place. AMPLIFY considers whether impact is communicated honestly enough to attract suitable partners. RESOLVE assesses whether risks are addressed before they become crises. SUSTAIN asks whether the results will endure after external support ends.
But this story is fundamentally about OWN, because it raises a question no signed handover letter can answer by itself: do local leaders control the system’s future, or only its paperwork?
Most technical assistance models never confront this question. A system is built and formally transferred, yet the relationship continues on the vendor’s terms because the operational knowledge, data sovereignty, and staff capacity required for independent management were never transferred. Ownership becomes a signature on a handover letter rather than a proven capability. A government can receive the same platform twice and still lack control over both its data and its operations.
OWN is designed to prevent that gap from emerging. It requires clear transition plans agreed at the outset, rather than negotiated under pressure after a government discovers it lacks the access it expected. It requires data sovereignty from day one, with government data hosted on infrastructure the government controls—not on a vendor’s servers. It also requires government-led implementation throughout, so that when external support ends, the system is run by the people responsible for its long-term operation, not by those trapped in a contract they cannot exit.
Before entrusting critical public infrastructure to an outside party, every government should ask more than who can build it best. It should ask who will run it and be accountable for it when the vendor leaves—and whether that transition was planned before the contract was signed.
The real lesson is not about one vendor. It is whether local leaders control the future of systems built in their name—or merely hold them on borrowed terms.
