Photo: Google Gemini · AI-generated
In most software projects, the question is whether the system works. In regulated ones, there is a second question that matters just as much: can you prove it works, eight months from now, to an auditor who was not in the room?
That second question sounds like paperwork. It is not. It changes the architecture.
When a bug is a regulatory event
Software teams have a working vocabulary for defects. Something is broken, someone files it, it gets fixed in the next release. That vocabulary does not survive contact with a regulated industry.
We built MedLabel for an ISO 13485-certified medical device manufacturer in Germany. The system generates UDI-compliant CE labels, warehouse bin labels, and item labels from the company’s product data. In that setting, a wrong label is not a formatting problem. It is a non-conformance — something that can trigger corrective action, delay shipments, and create regulatory exposure. The cost of the defect is not the fix. It is everything the defect sets in motion.
Once you accept that, the design brief changes. You stop asking “does it produce the right label?” and start asking “can it produce a wrong one at all?”
Correctness by design, not by procedure
There are two ways to get a compliant output. You can write a procedure and trust people to follow it. Or you can build a system in which the non-compliant version is not available.
MedLabel takes the second route: it enforces the required data fields for each label type, so the omissions that would make a label non-compliant cannot be saved and printed in the first place. Multilingual output is driven by the destination market rather than by an operator choosing a template, which removes another category of human error. The correctness lives in the software, not in someone’s memory on a busy production day.
This is the difference between a system that permits compliance and a system that produces it.
Traceability has to be structural
The same logic applies to records. Auditors do not ask whether you generally track things. They ask what happened to one specific batch, on one specific date, and expect an answer you can show.
That is why in MedERP — a multi-tenant ERP for a group of medical products and surgical instrument companies — batch, lot, and serial number tracking is built into every transaction rather than added as a reporting layer on top. Labelling in that system satisfies both EU UDI and FDA requirements, across multiple legal entities, countries, and currencies.
The general rule: traceability that is bolted on afterwards only records what someone remembered to record. Traceability built into the data model records what actually happened, because there is no path through the system that avoids it.
Change control is an engineering problem
Regulated software also cannot change casually. Every release has to be deliberate, documented, and reversible — which is a real constraint when a business still needs to move.
MedERP handled this by growing module by module: going live with what was ready while development continued on what was not, without disrupting operations already running in production. That is a delivery discipline as much as an architecture one — environment separation, QA and testing before each release, and a clear record of what changed and why.
The part worth stealing
Here is what we have taken from this work into projects with no regulator at all.
Enforced correctness beats documented correctness — every time you can make an invalid state impossible, you remove a class of failures permanently. Structural traceability answers questions you have not been asked yet. And controlled, documented change is how you stay able to release confidently in year four.
The point is: audit-ready is not a burden bolted onto good engineering. It is a stricter definition of it. Teams building for medical technology simply do not get the option of finding that out later.
If you are building something where “it works” has to be provable, we have done this before.