Originally drafted 12 August 2026. First published 7 October 2026; revised for publication.

Consider an illustrative procurement failure. A local authority launches an online permits platform after a year of procurement and implementation. Residents can submit applications without travelling to the office; staff can see queues that previously lived in paper files. Then a regulatory change requires a new approval step. The authority cannot make it. The supplier owns the configuration, the integration documentation is incomplete and the contract prices every change as a separate project. When the support agreement nears expiry, the authority discovers that moving its records, interfaces and service history will be harder than buying the original system.

The platform is not necessarily poor software. The procurement failed to buy the conditions under which a public service can be operated, adapted and held accountable over time. Digital sovereignty is not achieved by owning every line of code or keeping every server local; it is achieved when an institution can govern its data, change its service and preserve continuity without being trapped by a supplier.

That distinction matters across African public institutions, where digitisation often arrives through time-bound programmes, donor-funded implementation, outsourced hosting and scarce specialist capacity. A fast launch can solve a real access problem. But when procurement treats software as a finished product rather than a continuing operating relationship, it can convert today’s delivery pressure into tomorrow’s dependency.

The contract begins shaping the service before users see it

Public technology procurement is often framed around features: a portal, dashboard, case-management system, cloud environment or AI capability. Features are visible and easy to compare. They are also only one part of what a public institution is buying.

A service must remain available, secure and understandable. It must accommodate policy changes, correct records, connect responsibly to other systems and provide assistance when digital channels fail. It needs named owners, trained operators, incident procedures and a defensible route to replace or supplement a component. These conditions are designed early, in the requirements, evaluation criteria, data terms and acceptance tests.

In Digital Public Infrastructure: Setting Standards with the Hourglass Model, Abhishek Sankritik and Siddharth Shetty explain how a small set of core standards can support varied applications and underlying technologies. Their paper, prepared as background for the World Development Report 2025, also stresses context-specific governance and institutional mechanisms. It is the authors’ analysis, not necessarily the World Bank’s institutional position. The point is not that every public system must be open source or built in-house. It is that public value depends on the ability of authorised systems and institutions to work together without being permanently confined to a proprietary environment.

For senior officials, the procurement question changes accordingly. Instead of asking only, “Which supplier can deliver this system?”, ask, “What must remain true if the supplier changes, the policy changes, the budget tightens or an incident occurs?” The answer reveals the operating capabilities that the contract must protect.

Vendor lock-in is an operational risk, not a moral failing

Suppliers bring useful expertise, mature products and delivery capacity. There is no virtue in rejecting them simply because a service is outsourced. The problem arises when the institution cannot obtain its data in usable form, cannot understand the interfaces on which it depends, cannot run the service without a particular supplier’s staff or cannot negotiate a practical exit.

Lock-in can occur in several places at once. Data may be stored in an undocumented or costly-to-export format. Workflows may be configured through proprietary tools that only one party can change. Interfaces may be available only to selected partners. A cloud design may depend on services that cannot readily be reproduced elsewhere. Knowledge may sit with contractors who leave once a programme ends.

In their February 2025 World Bank blog on cloud adoption, Christine Zhenwei Qiang and Ghislain de Salins recommend multi-cloud approaches to reduce vendor-lock-in and supply-chain-dependency risks. That is not a universal instruction to use several cloud providers; unnecessary complexity can also undermine resilience. The useful principle is portability tested against the real service: can the institution recover its data, reconstitute a core workflow and maintain essential operations if a commercial arrangement changes?

An exit plan is not a sign that a relationship will fail. It is a condition for a relationship in which the public buyer can negotiate credibly. It should define ownership and formats for data; delivery of configuration, source code where agreed, and documentation; assistance during transition; security responsibilities; continuity arrangements; and the criteria by which a handover is accepted. Vague promises of “data ownership” do not solve these practical questions. The terms must be agreed within the applicable procurement, records and data-protection rules; they are not rights that every institution automatically holds.

Interoperability must be specified in the contract

Many projects promise integration. Too often, the result is a one-off connection that works for a narrow process and becomes difficult to extend. An API alone does not ensure that two institutions can use information responsibly. They must also agree what a record means, who is entitled to access it, how long it is valid and who resolves an error.

GovStack’s implementation playbook describes a component-based approach to interoperable, citizen-centred public services. The cited version is labelled 1.0.0-rc, a release-candidate playbook. It is guidance, not a binding standard or a ready-made national architecture. Its practical value lies in the procurement discipline it encourages: define reusable capabilities and interfaces around a service need, rather than buying a monolith that recreates the same function for every agency.

For a licensing service, that might mean using a stable business identifier, documented payment reconciliation and a governed method to verify an eligibility record. The authority does not need unrestricted access to every database held by another agency. It needs an authorised, auditable response to the specific decision it must make.

This approach aligns interoperability with privacy and accountability. Operational and personal data can remain in the systems responsible for them. A service can request the minimum necessary evidence through controlled interfaces. Logs can show who accessed what and why. Where multiple independent parties need shared provenance or settlement, a jointly governed registry may have a role. A ledger is not a substitute for data quality, lawful authority or service ownership.

Local capability is part of the system, not an optional add-on

A technically sound platform can still fail when the organisation cannot operate it. This risk is intensified when public teams face staff turnover, restricted training budgets, uneven connectivity and multiple layers of approval. A project that assumes a permanent pool of specialist administrators may work during implementation and become brittle afterwards.

Local capability does not mean that every task must be performed by government employees. It means the institution retains enough practical understanding to govern suppliers, assess performance, manage a change, handle an incident and protect the service’s purpose. The relevant people may include service owners, product managers, information-security staff, records officers, procurement teams and front-line support staff, not only developers.

Knowledge transfer must be observable. Contracts should not merely require training sessions. They can require role-based documentation, runbooks for common tasks, joint incident exercises, shadowing during configuration, and acceptance tests in which institutional staff complete key operational actions. These are modest disciplines with large consequences when a service reaches the point at which external support is unavailable or unaffordable.

They also make procurement fairer to local technology firms and implementation partners. Clear interface and documentation requirements allow smaller specialists to contribute to a service without needing to control the entire platform. This can deepen domestic capability while preserving competition and continuity.

Buy a service that can change under scrutiny

The best procurement specifications begin with a priority service journey and its public consequences. Consider a permit, benefit, licence or compliance process. Where does a person wait? Which records are repeated? Who makes the decision? What must be private, correctable and contestable? Which changes are likely over the next three years?

Discover the dependency map. Identify critical data stores, integrations, service providers, staff roles and manual workarounds. Do this before setting a technology architecture. It shows where loss of a single contract or system would disrupt a service.

Design the operating terms. Translate the service need into measurable requirements for availability, security, audit trails, accessibility, change control, data portability, documentation and incident response. Define which standards and formats are genuinely needed; a long list of fashionable specifications is not interoperability.

Build with a handover path. Test exports, interfaces, recovery procedures and administrator tasks during delivery, not at the end of a contract. Ensure that a new provider could understand the critical components without reverse-engineering the whole service.

Enable accountable operation. Give institutional teams ownership of the service outcomes and the evidence required to govern suppliers. Review performance through user completion, correction times, uptime, incident resolution, support demand and the cost of a change, not only feature delivery.

Xelius supports public institutions and delivery partners through service and workflow research, data architecture, interoperable platform design and implementation support. The immediate task is to identify the public service that cannot afford to become dependent on an opaque or unchangeable system.

Sovereignty is the capacity to decide and adapt

Digital transformation is often judged by launch dates and visible interfaces. Those measures miss the durability of the public capability being created. A service is stronger when its institution can explain its data flows, oversee its suppliers, correct its records and alter its rules without starting again from scratch.

That capacity is what turns a platform purchase into a public operating asset. It is also the standard against which procurement should be judged: not whether it delivered software once, but whether it left the institution able to serve, govern and adapt.