What I learned shipping software under GxP

I spent a good part of my career on software that ended up in hospitals and laboratories — clinical systems at Cerner, imaging at GE Healthcare, laboratory data systems at Waters. All under GxP-type requirements.

This article is not about standards. It is about what stayed with me afterwards, and why I think it was worth it even for projects where nobody asks me for compliance.

I am not going into details about systems or clients — everything below is general engineering lessons.

What surprised me at first?

That I could not start with the code.

I came from a way of working where you get a task, understand it from a conversation, build it, show it. Here, before the first line of code there was a chain: system requirement, software requirement, design element. It felt slow and pointless.

It took me a while to see what that slowness actually buys: clarity about what we are building, before we invest in building it. Half the conversations I have today on commercial projects — “but I thought it was supposed to do something else” — simply did not happen.

Why does “quick fix in production” not exist?

In an ordinary product, a hotfix is a win. You fix it in twenty minutes, deploy, move on.

There, a hotfix means: impact analysis, risk assessment, updating affected documents, retesting, approval. Not because someone wants to slow you down, but because a change made hastily in a system that influences a diagnosis can cause harm.

The side effect was interesting: when you know change is expensive, you invest far more in not getting it wrong up front. I wrote less code, but I thought about it more. And I came to prefer that.

Why is documentation written on time cheaper?

This was the most counter-intuitive part.

We all believe documentation is a tax paid at the end. In reality, the document written at the moment of the decision costs ten minutes. The same document reconstructed six months later costs a day — and is frequently wrong, because nobody remembers exactly why option B was chosen over option A.

What I kept: I write the decision down when I make it, briefly. Why I chose this, which alternatives I rejected, what trade-off I accepted. Not a formal document — a few paragraphs. On my own projects today, this is the only “process” I impose on myself, and it is the one that visibly pays for itself.

What did I carry into SaaS?

Four habits, all directly useful in unregulated products:

• Few, well-known dependencies. When every third-party library meant documentation and analysis, you learn to ask whether you actually need it. My dependency tree is still small — not out of purism, but out of habit.
• Reproducible builds. Being able to rebuild exactly what I shipped, at any time. It sounds mundane until the day you have to debug something that has been running at a client for three months.
• Bugs followed to the root. Not “fixed”, but: what caused it, what else it could affect, how I prevent recurrence.
• Tests as evidence, not as a net. A passing test not tied to a requirement gives me a false sense of safety.

None of these are specific to the medical domain. All of them are simply good engineering — it is just that there, you are not allowed to skip them.

What would I do differently?

Two things.

I would argue the classification instead of defaulting to the strictest. I have seen teams choose the strictest level across the whole system out of caution. It is a decision that costs a great deal — and it also gives up an argument you should be able to make anyway: the segregation rationale. The effort of arguing it properly pays back, but it comes with the obligation to defend it to an auditor.

I would ask for real data examples sooner. Many late surprises come from assumptions about what the data looks like in practice. An hour spent with someone who actually uses the system is worth more than a week of specifications.

Was it worth it?

If you want maximum speed and fast iteration, it is not your environment. If you want to learn how to build things you can genuinely trust — yes, and I think it makes you a better engineer wherever you go next.

I came away with an instinct I still rely on: if you cannot explain why you did something a particular way, you probably do not understand the problem yet.