In many Ghanaian institutions, IT appears inexpensive — at least on paper. Budgets are kept lean. Software is acquired sparingly. Hardware is stretched beyond its intended life. When asked, administrators will often say they are being prudent, managing scarcity responsibly, or avoiding unnecessary expenditure.
What rarely gets calculated is the cost of operating systems that are never fully owned.
Trial Software and the Illusion of Savings
A common practice illustrates this clearly: reliance on trial software licenses. Enterprise software is deployed using 30-day trials. When the license expires, another trial is activated — sometimes using a different email address, sometimes on a different machine. The system continues to function, superficially. From a distance, it appears operational. No invoice is issued. Money is "saved."
Trial software is not neutral. It is intentionally incomplete.
Critical features are disabled or restricted. Security updates may be delayed or unavailable. Audit logs are truncated. Backup and recovery functions fail quietly. Vendor support is absent by design. The system operates in a degraded mode — but the degradation is undocumented and normalized.
Over time, the institution trains itself into fragility. Staff learn that systems are temporary and unsupported. When something breaks, repair is not expected — workarounds are. Data is exported to spreadsheets. Official workflows are bypassed. WhatsApp becomes the real system of record. The deployed software exists mainly for inspections and reports.
The costs surface elsewhere
- Repeated data loss
- Security exposure
- Unreliable reporting
- Staff time wasted rebuilding what should have been persistent
What the Numbers Actually Show
Consider a modest institution running a trial-based system used by five staff members. Each loses just 30 minutes per day to workarounds — re-entering data, recreating lost reports, fixing sync issues, or waiting for systems to recover. That's 2.5 hours per day across the team.
| Item | Calculation | Cost |
|---|---|---|
| Daily lost time (5 staff × 30 min) | 2.5 hrs/day | — |
| Monthly lost hours | ~50 hrs/month | — |
| Internal cost at ₵30/hr | 50 × ₵30 | ₵1,500/month |
| Annual hidden cost of trial software | ₵1,500 × 12 | ₵18,000/year |
| A legitimate annual license for the same system: ₵6,000–₵10,000. The trial approach triples the cost — quietly, indefinitely, and without accountability. | ||
And this excludes the cost of data loss, security incidents, reputational damage, and staff frustration and turnover. Those costs are real. They simply don't appear in procurement documents.
"We Simply Don't Have the Budget" — and Why It Fails
The most common defense is straightforward: "We simply don't have the budget. The choice isn't between licensed software and trials — it's between trials and nothing at all." This argument sounds pragmatic. It collapses under scrutiny.
First, the institution is already paying — just not transparently. Staff time, data loss, and operational disruption are real costs, even if they don't pass through procurement. Choosing trials does not eliminate expenditure; it reallocates it to the least efficient place possible.
Second, trial dependence makes systems un-auditable and indefensible. When something fails, there is no vendor support, no SLA, and no accountability chain. The institution assumes all risk while pretending it assumed none.
Third, this approach blocks long-term planning. Because the system is unofficial, it cannot be budgeted for properly, improved incrementally, or integrated with other systems. It remains permanently provisional — never reliable enough to depend on, never abandoned enough to replace.
The "we can't afford licenses" argument confuses avoiding payment with avoiding cost. The former is temporary. The latter is impossible.
Operational Debt and the Miscalculation of IT
This logic repeats across infrastructure. Systems are designed as if power is stable, even where outages are frequent. Connectivity is assumed rather than engineered around. Maintenance is excluded from budgets because it does not produce visible outcomes. Responsibility for system health is assigned to individuals rather than roles — guaranteeing collapse when those individuals leave.
The result is not technological failure, but economic miscalculation. IT is treated as a one-time purchase rather than as infrastructure that demands recurring investment. Institutions optimize for low upfront cost while quietly accumulating operational debt.
Eventually, that debt comes due. The system may still "exist," but it no longer serves its intended purpose. It produces unreliable data, erodes trust, and reinforces the belief that digital systems cannot be sustained in these environments.
That belief is incorrect. The failure lies not in the technology, but in the refusal to account for its full cost.
Reliable systems require ownership — of licenses, of maintenance, of failure, and of recovery. Avoiding those commitments does not eliminate cost. It merely relocates it, usually to the worst possible places.
Walter Kwami writes from over 30 years in IT, with particular interest in how technology must be engineered — not merely adopted — in resource-limited contexts.