What building government systems taught me about shipping software

Most engineering advice is written for startups. Move fast, break things, iterate. That advice does not survive a room full of civil servants who need the payroll system to work on the 1st of the month, every month, forever.

I spent five years building and running systems inside a government electricity company. Here is what that context taught me that no tutorial did.

Uptime is a promise, not a metric

In a startup, a five-minute outage is a Slack message. In a ministry, it is a queue of people who took the day off work to file a complaint. That reframing changes how you build:

• Deploy behind Docker so a bad release rolls back in seconds, not hours.
• Keep the database boring. Postgres and MySQL have run the world for decades.
• Test the unhappy path first — the network drop, the half-filled form, the double submit.

Simple systems win because someone else has to run them

You will not always be the person on call. The people who inherit your system may not read your language, let alone your code. So the best architecture is the one a tired person can reason about at 2am.

The measure of a system is not how clever it is. It is how calm you are when something goes wrong at the worst possible time.

Requirements are a conversation, not a document

The spec I was handed and the system people actually needed were never the same document. The gap only closed by sitting with the people doing the work and watching them fight the old process.

That habit — build the smallest useful thing, show it, adjust — is the single most valuable engineering skill I have. It has nothing to do with any framework.

What I still carry into every product

Whether I am building Basiq for a café or a citizen portal for a ministry, the same rules apply: prefer boring technology, design for the person who will run it at 2am, and treat uptime as a promise to a human being — not a dashboard number.