What it actually costs to run a system after launch

The short answer, in UGX

The bands below are what it costs to keep a system alive, secure and useful, not what it costs to park it on a server. The difference between the two is the whole point of this article, because parking a system on a server is close to free and is what most Ugandan organisations are unknowingly paying for. What moves a running cost is not traffic, which is what people assume. It is the consequence of the system being down or wrong. A brochure site that is unreachable for two hours on a Sunday costs nothing. A fees system that is unreachable on the morning of a payment deadline costs a school its entire week, and pricing the support around that is what the upper end of these bands pays for.

• A website or small business system: from UGX 600,000 a month
• An organisation running a programme on it: UGX 1.5 to 3 million a month
• A platform an entity depends on daily, with a response obligation: UGX 3 to 6 million a month
• SMS, payment gateway fees and similar pass-through costs sit on top and scale with use

What the money actually buys

Most of this list is invisible when it is working, which is exactly why it gets cut from budgets. Nobody has ever been thanked for a security patch. The items matter in a specific order: hosting keeps it reachable, backups decide whether a bad day is an inconvenience or a catastrophe, patching decides whether you are a target of opportunity, and the response obligation decides whether any of the first three get done on the day they are needed rather than the week after. The last item on the list is the one organisations argue with and the one they end up needing most, because the work a system measures always changes, and a system that cannot change with it is abandoned rather than maintained.

• Hosting sized to the actual load, on infrastructure the client owns or controls
• Daily backups, held somewhere other than the server being backed up
• A restore that has actually been performed, not just configured
• Security patching of the operating system, the runtime and the dependencies
• Monitoring that tells somebody it is down before a user does
• A named person to call, with a response time written into the contract
• A standing allowance for change, because the work the system measures will change

The failure mode is year two, and it is predictable

The pattern is consistent enough to describe in advance. A system is commissioned with a build budget and a launch date. It launches, it works, everyone is pleased, and the vendor is paid the final instalment. For the first several months nothing goes wrong, which is taken as evidence that nothing needs paying for. The operating line is not renewed in the next financial year, either because it was never in the budget or because it looks like an easy saving against a system that is visibly fine. Somewhere in the second year a dependency reaches end of life, or a certificate expires, or a disk fills, and there is no longer anyone contracted to notice. The organisation then discovers that the people who built it have moved on, the documentation is two versions stale, and the cost of recovering the system approaches the cost of having built it. This is not a technology problem and it is not caused by bad code. It is caused entirely by a budget line that was never created.

A backup you have not restored is not a backup

This deserves its own section because it is the single most common false comfort in Ugandan software, and it is held sincerely. Almost every organisation we have audited believed it had backups. A meaningful proportion had backup jobs that had been failing silently for months, backups written to the same disk as the database, or backup files that existed and could not actually be restored because nobody had ever tried. A backup is a claim about the future, and the only way to test a claim about the future is to rehearse it. Ask your provider when they last performed a real restore of your system into a working environment, and how long it took end to end. If the answer is that the job runs nightly and has never errored, you do not have a tested restore, you have a green light on a dashboard. Building the rehearsal into the monthly retainer is cheap. Discovering the gap during an actual incident is not.

What changes every year, and why you should plan for it

A system is not a building, and the instinct to treat it as one is where the budgeting goes wrong. Fee structures change, grading rules change, a funder changes its reporting template, a ministry adds an indicator, a payment provider changes its API, a browser deprecates something the interface relied on. None of these are defects and none of them are anybody's fault, but each one is work. Organisations that budget a few days of change per quarter keep their system matching reality and keep using it. Organisations that treat every change as an unbudgeted emergency end up with staff maintaining a parallel spreadsheet because the system no longer reflects how the work is actually done, at which point the system is decorative and the real records are somewhere else entirely.

What to put in the contract

Write the operating terms down while you still have leverage, which is before the build is paid for rather than after. The clauses that matter are unglamorous and short. Specify the response time in hours and say what counts as a critical incident, because those two together are the whole of the support promise. Specify that backups are tested and that you receive evidence of the test. Specify that you hold the hosting account, the domain and the credentials, and that the vendor works inside your accounts rather than their own. Specify what happens at the end: what you are handed, in what form, and how long the vendor will support a transition to somebody else. A vendor confident in their work will agree to all of this without argument, because none of it costs them anything if they intend to do the job properly.

• Response time in hours, and a definition of a critical incident
• Tested restores, with evidence provided to you
• You hold the domain, hosting account and credentials throughout
• A named contact, and what happens when that person is unavailable
• Handover terms: what you receive, in what form, and transition support