Writing software for a government department is not writing a product. The user cannot choose a competitor, the requirements arrive as policy rather than as research, and the system will outlive several of the people who commissioned it.
Those three facts should shape the architecture, and usually do not.
The workflow is the specification
In a commercial product you design a flow and measure whether people complete it. In a public-sector system, the flow already exists — as a rule, a form, and an approval chain that predates the software by decades.
Your job is not to improve it. It is to represent it faithfully, and only then to point out where it contradicts itself.
This is the single largest source of failure. A budgeting system that models a plausible approval chain instead of the actual one is not a system with a bug; it is a system nobody can legally use.
Audit is a feature, not logging
Commercial software logs so engineers can debug. Government software records so that a decision can be reconstructed years later, possibly in front of someone whose job is to find fault with it.
That is a different requirement. It means:
- Append-only history for anything that affects a financial or legal outcome.
- Recording who and why, not just what and when.
- Data that survives the application being rewritten.
Design this in at the schema level. Bolted on afterwards, it is never complete enough to be trusted.
Assume the network is bad
Systems used in district offices meet intermittent connectivity, ageing hardware, and browsers a few versions behind. Deciding that these are the user's problem is a decision to be unused.
Server-rendered pages, forms that survive a dropped connection, and modest payloads are not old-fashioned choices in this context. They are the ones that work.
Build for the handover
The system will be maintained by people you will never meet, with less context and less time. That argues for boring technology, conventional structure, and documentation of why rather than what.
The most valuable thing you can leave behind is not clever code. It is a system the next engineer can change without being afraid of it.