Software a regulator can audit, written by the people who will maintain it.
We build medical device software to IEC 62304, in Australia. Regulation is mostly an evidence problem: it is not enough that the software works, you have to be able to demonstrate you knew it worked before you shipped it, and that you would find out if it stopped.
Regulation is an evidence problem
Most teams discover this late. The code is finished, it behaves, and then somebody asks for the documentation that proves it was built the way the standard requires — and it has to be reconstructed from memory, commit messages and good intentions. Reconstructed evidence is both the most expensive kind and the least convincing.
We produce it as the work happens, because that is the only point at which it is cheap and the only point at which it is true. The documentation is a deliverable with the same status as the software, not a thing written afterwards to satisfy somebody.
- Documentation maintained as a deliverable, versioned with the code
- Test coverage that constitutes evidence rather than reassurance
- A traceable change history that survives scrutiny years later
- Handover packs written to survive staff turnover
What IEC 62304 actually asks for
IEC 62304:2006+A1:2015 is the current edition, and it is the one you can declare conformity to. It defines a software life cycle: planning, requirements, architecture, detailed design, implementation, integration, testing, release, and then maintenance and problem resolution as processes in their own right rather than as what happens after the project ends.
How much of it applies depends on the software safety class — A, B or C — which follows from what happens if the software fails. A is the lightest, C the most demanding, and the class drives how much of the standard you must satisfy rather than whether it applies at all.
Edition 2 is in committee draft and is expected to replace those three classes with two process-rigour levels, along with explicit handling for machine learning and for cybersecurity in design control. The IEC currently lists it for late 2028, and it has already slipped once. Until it is published and harmonised, the 2015 edition is the one that counts — and anyone telling you otherwise this year is reading a projection rather than a standard.
- Software development planning, and keeping the plan true as it changes
- Requirements and architecture recorded as the design decisions they are
- SOUP identified, justified and monitored
- Problem resolution and maintenance as live processes, not a closing phase
What we do, and what we do not claim
We are currently building a TGA-regulated medical device portal — front end, API, design system and hosting. One small team does all of it, which is most of why the evidence trail holds together: there is no handover between the people who designed it and the people who maintain it, because they are the same people.
What we are not is a certification body, an auditor, or your regulatory affairs function. We do not issue conformity assessments and we do not sign off on your submission. We build the software and we produce the evidence that goes with it, to the standard your product is held to, in a form the people who do sign off can actually use.
- Front end, API, database and design system, built in house
- Hosted on hardware we own, in Australia
- The people who scope the work are the people who write it
- WCAG 2.2 AA as a floor, including in regulated products