What separates a government project from a private-sector one is not data volume or user count. It is that the entity answers to oversight bodies, that any change may be questioned years later, and that its data is not the IT department's property but a public trust. Systems here are judged by different criteria.
Four controls we build around
1. Data does not leave the premises
The system runs entirely on the entity's own servers: database, application layer and backups. No dependency on an external cloud service for operation, for licensing, or for receiving updates.
This deserves scrutiny when evaluating any proposal. Many systems described as "on-premise" still require an outbound connection for licence validation, which means an internet outage or a soured commercial relationship can halt them. Ask every vendor that question directly.
2. An audit trail that cannot be bypassed
Every change is recorded: who, when, and the value before and after. Critically, the recording happens in the database layer rather than the interface, so it cannot be circumvented by reaching the data another way. That includes the approvals themselves — who approved, when, at what value, and whether they acted in their own right or under delegation.
3. Row-level permissions
In weaker systems a "permission" means a hidden button, while the data remains available to anyone who knows how to reach it. Here permissions are enforced inside the database at row level: a member of staff without rights to a department is not returned its rows at all.
That enables what entities actually need: a department seeing only its own data, a central administration seeing the consolidated picture, and an auditor seeing everything read-only.
4. No vendor lock-in
An entity should not be captive to any vendor, including us. We therefore write an explicit clause into the contract: at its end, data is handed over in full in a usable format with its structure documented, together with system documentation and operating procedures.
A question worth asking every vendor
"If we terminated tomorrow, what exactly would we own, in what format, and how long would handover take?" A vague answer to that question is a more serious warning sign than any gap in a feature comparison.
Connecting to existing systems rather than replacing them
Government entities typically run existing systems, some old but functioning and bound to approved procedures, which cannot and should not be replaced by a technical decision alone.
The better entry point is therefore usually adding a layer above what exists: analytics and dashboards reading from current systems, or automating an approval cycle that runs on paper today, without touching the system itself. Tangible impact at low risk — which suits an environment that cannot tolerate service interruption.
What can be deployed
- Financial systems — general ledger, budget, commitment and disbursement, with oversight reporting.
- Stores and custody — item balances, personal custody records and periodic stock counts.
- Procurement — request, approval and supply with a complete audit trail.
- Personnel and payroll — covered in more depth here.
- Projects — execution and cost tracking, with a dedicated system for construction projects covering certificates and retention.
How we usually start
With a limited, clearly bounded scope and a fixed go-live date, rather than a comprehensive programme spanning years. Government projects that stall have usually not stalled technically — they stalled because scope stayed open until decision-makers lost patience with them.
A good first scope is one whose impact a non-specialist can see within a few months: a report that took a week becoming immediate, or a paper approval cycle becoming recorded.