Building a medical software product, from design to delivery
I design and build your medical device software, with a team I assemble and lead, through to a product that holds up in clinical use and in front of the file.
What I design and build
The starting point varies. Sometimes it is a blank page and a clearly identified clinical need. Often it is a research prototype that works in a demo, in the hands of its author, and that will survive neither the first real user nor the first question from an assessor. I take on the overall design: what the software does, what it will not do, how it breaks down into items, where the boundaries run with the device, with the hospital information system and with the most safety-sensitive processing. Then the build: the back end, the image processing or the learning models when the product depends on them, the user interfaces, integration and the delivery pipeline. Technical choices follow the need, never the other way round. Software in a high safety class imposes a verification discipline that a convenience feature does not justify; conversely, over-constraining a secondary module burns time that will be missing where the risk is real. Good architecture in medical software is, first of all, a good distribution of constraint.
The team, assembled and led
I do not turn up alone with a fixed price and an anonymous team behind me. Depending on your situation, I lead your developers, I build a team around them, or I stand up a complete team for the duration of the project. Hiring for medical work calls for a particular kind of screening. Engineering level is not enough: you need people who accept that a feature is specified, traced, verified and documented before it counts as done, and who do not experience that demand as a punishment. It is as much a matter of temperament as of competence, and it can be spotted in an interview when you know what to look for. Once the team is in place, I lead it the way a CTO leads their own: design reviews, code review, short rituals, written decisions. You have a single point of contact and direct access to what is happening — code repository, task tracking, real progress rather than a progress report. I have never seen a medical project degrade because the client knew too much; the opposite, on the other hand, happens constantly.
Compliance, built in from the first line
Compliance is not a final phase. It is either built into the product or reassembled at the end — and reassembling always costs more than building, in money as in credibility. In practice, requirements live in a system linked to tests and risks, not in a spreadsheet updated the night before a review. The IEC 62304 software life cycle is applied at the pace of development: planning, specification, detailed design for the items that require it, verification and version management. Risk analysis in the ISO 14971 sense advances with the design and comes back down as verifiable requirements, which is its only real use; a risk analysis that never changes the software is just a document. Software of unknown provenance is identified, justified and tracked from the moment it is introduced, because discovering it late is one of the surest ways to lose a quarter. I promise neither an assessment timeline nor an outcome with a notified body: that does not depend on me alone. What I commit to is the quality of the file you will present and its consistency with the software actually shipped.
Handover to your teams
Medical device software lives on long after it first reaches the market. Corrections, evolutions, a version change in a third-party component, post-market surveillance: all of it lands on someone. The project has to be designed for that someone, from day one. So I document for the team that will take over, not for the auditor. Architecture decisions are written down with their reasons and the alternatives that were rejected, the development environment rebuilds from the repository, the build and test pipeline is reproducible from one machine to the next. The handover itself happens in overlap: your developers work on the product while my team is still there, with real tasks and not a tutorial. That is the only way to check that the handover works while it is still possible to fix it. If you do not yet have an in-house team, the exit is organised differently: coached hiring during the project, or keeping part of the team on under your own contract. We discuss that at scoping, not at delivery.
Let’s talk about your product
A credible peer, in the boardroom and in the operating theatre.