How to choose a software partner for a government contract in Uganda

The one question that separates vendors

Ask every shortlisted firm to name a system they built that they are still operating today, and to say who pays them to operate it. That single question does more filtering than an entire technical evaluation, because almost every software company in Kampala can show you a launch. A launch proves that code was written and that somebody cut a ribbon. It does not prove the system survived contact with real users, real data volumes and the second year of its life, which is where most government systems quietly die. A vendor who still runs something has had to answer for it every week since it went live. They have been woken up by it. They have migrated it through a server move, patched it through a vulnerability disclosure, and explained to somebody senior why a number on a dashboard changed. That history is not something a proposal can fake, and it is the closest thing procurement has to a guarantee that the same thing will not happen to you.

What to ask before you shortlist

These questions are deliberately awkward, and that is the point. Each one is easy to answer for a firm that has actually operated a system and uncomfortable for a firm that has only delivered builds. Send them in writing before the technical presentation, because the presentation is where a good salesperson wins and the written answers are where an operator does. Pay particular attention to the third and fourth: a vendor who cannot tell you what their systems cost to run is a vendor who has never had to pay for it, and a vendor who has never restored from a backup does not have backups, they have files they hope are backups.

• Name a system you built that you still operate. Who pays you to run it, and since when?
• What happened the last time one of your systems went down? Who noticed first, you or the client?
• What does it cost to run the systems you have built, and who pays that after the build invoice is settled?
• When did you last restore a client system from a backup, and how long did it take?
• Who on your team will still be on this project in eighteen months, and what happens if they leave?
• Show us a system you handed over. Can the client change it without you?

The compliance pack, and why the timing tells you something

Every serious procurement asks for the same bundle: certificate of incorporation, memorandum and articles, tax registration, beneficial ownership, registered office, and increasingly a tax clearance certificate. What matters is not whether a firm can produce these, since eventually everyone can. What matters is how long it takes. A company that keeps its statutory file current sends registrar-certified copies within the hour, because they are sitting in a folder. A company that has let filings lapse disappears for four days and comes back with a signed form rather than a registered one, which is a different thing entirely. A signed form is the company's own paperwork and proves only that somebody signed it. A registrar-certified copy carries the registry's stamp and proves the filing was accepted and recorded. If you are evaluating on a deadline, ask for the certified copies specifically, and treat the response time as part of the evidence.

• Certificate of incorporation and company registration number
• Memorandum and articles of association, certified
• Tax registration certificate, current, and a tax clearance certificate if the procurement requires one
• Beneficial ownership filing, as the registrar returned it, not as you submitted it
• Registered office and postal address on the register

If you are a prime looking for a local executor

A firm that has won a contract and needs somebody on the ground in Uganda is buying something different from a ministry buying a system, and should evaluate differently. You are not buying a vendor, you are buying the part of your own delivery risk you cannot personally supervise. The things that matter are whether the local partner can work inside your contract and your standards rather than insisting on their own, whether they can be audited by your team without drama, and whether they will still answer the phone when the work is unglamorous. Ask directly what happens to the work if your scope changes mid-delivery, because it will, and a partner whose answer is a change request rather than a conversation is going to cost you more than their rate suggests.

• Can they deliver inside your contract, your repository and your review process?
• Who is the named person accountable to you, and is that person on the build?
• What is their position on your client owning the code and the data outright?
• How do they handle a scope change that is not their fault?

What a good answer on running costs sounds like

Ask what the system will cost to run each year after handover, and listen to the shape of the answer rather than the number. A vendor who says it depends and moves on has not thought about it and will not be there. A vendor who names a figure, breaks it into hosting, backups, monitoring, support response and an allowance for change, and then tells you which of those the ministry could take in house, has run systems before. The second answer is also the one that protects your budget, because the running line is where government systems in Uganda actually fail. They are commissioned with a build budget and no operating budget, and by the second financial year nobody is patching the server that holds the data. A vendor who raises this before you do is telling you they have watched it happen.

Evaluate the handover, not just the build

The last thing to check is what you are left holding if the relationship ends. Ask to see the documentation from a completed project, not a template, and ask whether the client could take that repository to another firm and have them productive inside a week. Ask who holds the domain, the hosting account and the database credentials during the contract, and who holds them after. A partner who is comfortable with you owning all of it from day one is a partner confident you will keep them for reasons other than lock-in. A partner who becomes vague at this question has a commercial model that depends on you not being able to leave, and that model eventually costs a government entity more than the original build ever did.