A government system outlives the person who asked for it, and it has to. The officer who commissioned ours sat through the scoping meetings, understood exactly why each awkward decision had been made, and was posted elsewhere before we had finished shipping. That is not a mishap. It is how the service works: people rotate on a cycle measured in a year or two, and the institution stays behind them. So the first thing public-sector delivery teaches you, before any of the technical discipline, is that your system cannot depend on anyone remembering why it exists. Eighteen months after handover, the person raising a ticket about it will not know our name, and will have no reason to.
We learned this properly on the digital platform for a state tourism corporation: public booking for boat rides, hotels and tour packages, online payments and QR ticketing, an executive analytics layer, and native apps for the phones people actually carry. It replaced an ageing Java and Spring Boot system on Oracle whose reporting schema had grown past five hundred tables, accreted over years of hotel and tour operations. Nobody currently employed there could tell us why half of those tables existed. Some were certainly dead. And that, if you follow the thought a step further than is comfortable, is the future state of everything we were about to build. One day we will be the people who have retired, and our five hundred tables will be the ones nobody can explain.
You build for the amnesia
In private work, handover documentation is the thing you promise in the proposal and thin out under deadline. The client has an engineering team, or will hire one, and if the docs are patchy someone can always come and ask you. In public work there is often nobody to ask, and no budget line to bring you back to explain. So the runbook, the architecture note, the boring document that says which service talks to which and what to do when the payment reconciliation job falls behind, stops being an afterthought and becomes the system's memory. It is the only part of the delivery that survives the transfer of every human who was in the room.
I will admit we did not fully believe this going in. Two of us argued that writing a documented restore procedure and a proper operations runbook for a platform we were also going to operate was gold-plating, effort spent on a scenario that would not happen. We were wrong, and the thing that changed my mind was watching the questions arrive from people who had inherited the relationship and started from zero knowledge. The docs were not for a hypothetical successor. They were for a real person, six months out, who was owed an answer we would not be around to give.
The audit trail comes before the feature
Access to a public system has to be provable, and records have to be auditable, and those two sentences reorder how you build. On the tourism platform we wrote the audit trail before we wrote the booking flow it was going to audit. That feels backwards. It is not. If you cannot show who did what and when, then as far as the department is concerned the feature is not finished, because the feature is not just the booking, it is the accountable record of the booking. A private client will usually let you add audit logging later, when a customer asks or an incident forces it. A public buyer treats the untraceable action as the defect it is, on day one.
Procurement asks for engineering and calls it paperwork
A lot of what a government procurement process demands reads, on first pass, like bureaucracy for its own sake. A documented backup and restore procedure. A stated response and resolution commitment, in writing, before the contract. Handover documentation and a runbook the department's own people can work from. It is easy to roll your eyes at the forms. But go through them one by one and every single item is good engineering wearing a form's clothing.
- A backup you have never actually restored is a rumour about a backup. The form that asks you to document the restore is quietly asking you to have performed one.
- A response commitment you have not written down is a hope, and hope degrades the week after go-live, which is precisely the week the risk is highest.
- Handover documentation is the department refusing to rent a system it is supposed to own. A platform only its vendor can maintain is a liability dressed as an asset, and procurement is right to price that in.
None of this is unique to government. Every serious private buyer should want the same things. The difference is that government makes you prove them, and private clients mostly take your word.
The public did not choose you
This is the part that changed how I think about the whole job. The people using a public system are not customers who picked us over a competitor. A family trying to book a boat ride cannot switch to a rival tourism corporation because our interface annoyed them. They are stuck with what the state provides, which means accessibility and offline access are not growth tactics you invest in to widen the funnel. They are ethical obligations, because the person on the other end has no exit.
So the issued ticket is cached on the device and read back when the network is gone, because the honest picture of the user is a visitor standing at a jetty at eleven in the morning with one bar of signal and a phone that cannot reach our API, and a boatman who wants to see a valid ticket now. Authentication is a one-time code sent to a phone rather than a password, because the phone number is the one stable thing that person carries and a password is a thing to forget. When a private user hits a wall, they leave and you lose a sale. When a citizen hits a wall, they are simply unserved by their own government, and there is nobody else to go to. That reframing raises the floor on everything, and once you have felt it you cannot build a shabby offline path for a private client either.
Slower, and sometimes that is correct
Public delivery is slower, and I have made my peace with the fact that some of that slowness is right. A change that cannot be quietly rolled back, that touches money the public has paid, deserves more deliberation than a startup's Tuesday deploy. The procurement cycle can be longer than the build itself, which is genuinely maddening when you are ready to work and waiting on a file to move between two desks. But the caution around the thing once it is live is not the same as the caution before it starts, and I have stopped conflating the two. One is friction. The other is respect for the fact that a boat booking is a real family's real day.
The thing that genuinely frustrated me
It is not the paperwork. It is the waiting, and what the waiting does to a design. A procurement cycle that runs longer than the build means you sit with a team ready to work while a file moves between two desks, and the system you scoped six months ago quietly ages while it waits for a signature. Nobody is at fault in any way you could point at, which is the most frustrating kind of fault there is.
The other one is institutional: you inherit integrations with systems whose owners retired two reorganisations ago. There is nobody to ask how the interface is supposed to behave, no document that describes it, and no test environment. You reverse-engineer it from what it does rather than what it should do, you write down what you find, and by the end you are the closest thing that system has to an owner, which is a strange thing to become by accident. This is the accumulated condition of a lot of public software everywhere, not a fault of any one department: underfunded, passed between contractors, held together by people doing their best without the tools to do better. It is a criticism of how we fund and hand over public software, and we are all implicated in it.
The audit-trail-first habit is the one that came home with us. We now build the record of what the system did before we build the pleasant part the client will demo, on private engagements too, and no private client has ever objected once it is there. They just assumed, as we used to, that it was something you add when you need it. You do not. You need it the first time something goes wrong, and by then the person who could have explained what happened has been posted somewhere else.