What donor-funded digital projects should demand from vendors

Donor-funded digital projects share a familiar shape. A system is specified, procured and delivered within a funding window. The vendor demonstrates it, the project closes, and the ministry is left to run it. Too often, that is when the institution discovers that it does not hold the source code, cannot change a form without a paid change request, does not know where its data is hosted, and has no staff who understand how the system works. None of these problems are technical. They are contractual, and they are decided at procurement. Permanent secretaries, project coordinators and donor programme officers have a shared interest here: the investment should leave behind a capability, not a dependency. The following requirements are worth writing into the terms of reference and the contract, with acceptance tied to evidence rather than assurances.

Ownership of code, data and documentation

• The government owns, or holds a perpetual, irrevocable and transferable licence to, all custom source code, configuration and scripts produced under the contract.
• Source code is delivered into a repository the institution controls, continuously throughout the project, not as an archive at the end.
• Where the solution relies on a commercial product, the licence terms, renewal costs and what happens if licences lapse are disclosed in the bid.
• All data, including metadata and audit logs, belongs to the institution and can be exported at any time in documented, open formats without additional charge.
• The institution can build and deploy the system from the delivered source without the vendor's involvement, and this is demonstrated before final acceptance.

Documentation is often accepted by weight. The test should be whether a competent engineer who has never seen the system could operate, maintain and modify it. Require architecture documentation, data models, interface specifications, deployment and configuration guides, operational runbooks, and user manuals in the languages the staff actually work in. Make delivery of each a milestone with its own acceptance criteria. Insist that documentation is kept in the same repository as the code and updated with every release, so it describes the system as built rather than as originally proposed.

The real test of a donor-funded system is whether the ministry can run it the day after the vendor leaves.

Handover and training as deliverables

Training is frequently a few days of classroom sessions at the end of the project, delivered to whoever is available. Effective handover is structured and continuous. Name the civil servants who will own the system, involve them from the design phase, and have them pair with vendor engineers on real tasks. Distinguish between end-user training, system administration and technical maintenance, and require each to be assessed.

• A named counterpart team inside the institution, with time formally allocated to the project.
• A training plan with learning outcomes per role, and evidence that each person can perform the core tasks unaided.
• Train-the-trainer materials the institution may reuse and adapt freely.
• A shadow period in which institution staff perform operations while the vendor observes and supports.

Security testing evidence and hosting

A statement that the system is secure is not evidence. Require the vendor to describe its secure development practices, to remediate findings from an independent penetration test commissioned by the institution or the donor, and to provide a software bill of materials listing third-party components and their versions. Specify a minimum baseline: role-based access control, multi-factor authentication for administrators, encryption in transit and at rest, audit logging, and a vulnerability disclosure and patching commitment for the support period. Reference recognised frameworks such as ISO 27001 or the OWASP Application Security Verification Standard so that expectations are measurable. Where data is stored, and under which jurisdiction, matters for citizen data, financial records and anything subject to national law. The contract should state the hosting location, the legal entity operating it, who holds administrative credentials, and how backups are stored and tested. If hosting is in a vendor's own account, the institution should hold root-level access and be able to move the workload. If national data protection rules apply, map them explicitly to the hosting design rather than assuming compliance.

An exit plan, and how to avoid lock-in

Every contract ends. Require a costed exit plan as part of the bid, describing how data, code, credentials, domain names, certificates and documentation will be handed over, in what formats, and within what period. Include an obligation to cooperate with a successor vendor at defined rates. Test the plan before the project closes by having the institution or an independent party restore the system from backups into a separate environment. The plan should also name the institution's own staff who will receive each item, so that handover has a recipient as well as a sender. An exit plan nobody has read is not a plan.

• Prefer open standards for data exchange and identity, so the system can integrate with others without bespoke connectors owned by one vendor.
• Ask bidders to price ongoing support separately from the build, and to state the rates for changes after go-live.
• Avoid requirements that only one product can meet unless that choice has been justified independently.
• Ensure domain names, cloud accounts and certificates are registered to the institution, not to the vendor or an individual.
• Retain the right to have any qualified party maintain the system.

Common pitfalls

• Final payment released on go-live rather than on successful handover and demonstrated independent operation.
• Support period funded by the project but no budget line for the years after it, so the system decays.
• Requirements written by the vendor that will later bid, which narrows competition from the outset.
• No named owner inside government, so nobody is accountable for the system once the project unit disbands.

None of these requirements is unusual, and capable vendors will meet them without difficulty. Those that resist them are telling the institution something useful. Writing them in at procurement costs little; discovering their absence after the funding window closes can cost the whole investment. Donors can reinforce the point by making these terms standard in their own templates, so that ministries are not left to negotiate them alone.