Services

Technical project management, software and application development, and AI integration, with most of the experience in medical devices and other regulated industries, where how a product was built has to be shown, not just claimed. Engagements run from a short review to building and shipping a product end to end.

Medical devices and regulated industries

In a regulated product the evidence is part of the product. A medical device is not finished when the software works; it is finished when you can show why it is designed the way it is, that every requirement was met, and that the risks were found and brought under control. That runs through everything below.

Design controls are the backbone. User needs turned into design inputs that can be tested, design outputs traced back to them, design reviews at the points that matter, verification and validation that prove what they claim, a controlled transfer to production, and a design history file an auditor can follow without you in the room.

Design controls

ISO 13485 clause 7.3 and the FDA's quality management system regulation (21 CFR 820): plans, inputs, outputs, reviews, verification, validation, transfer, changes, the design history file.

Software

IEC 62304, the medical device software life cycle, scaled to the software safety class.

Risk

ISO 14971: hazards, risk controls, and proof that each control works.

Usability

IEC 62366: use errors treated as risks, and summative evaluation planned from the start.

Quality system

ISO 13485, which the rest lives in; the EU MDR and FDA submissions, which it all feeds.

The aim is discipline that helps the project instead of slowing it: documentation written as the work happens, not reconstructed in the weeks before an audit.

Best practices for device programmes: project management → · project governance →

Technical project management

Someone has to hold the whole shape of a project in their head: what depends on what, which estimate is optimistic, which risk is actually going to bite, and what can be cut without gutting the thing. That is this work.

It is not administration. It is technical judgement applied to delivery — reading the code to know whether a two-week estimate is credible, and telling you in time to do something about it.

On a medical device that includes the design control plan: phases and design reviews, a traceability matrix kept current from user need to test result, change control that does not freeze the team, and a verification and validation plan that is ready before the build is.

Agile, waterfall, and what fits

Both are tools, and regulated projects need parts of each. Waterfall's phase gates and formal reviews map naturally onto design controls; agile's short iterations keep risk visible and catch a wrong requirement while it is still cheap. The work is combining them, so that each sprint produces design outputs, reviews and traceability as it goes (the approach AAMI TIR45 describes), rather than picking one on principle.

From regulatory strategy and phase gates to design transfer and post-market surveillance: best practices for medical device projects → Decision rights, gate outcomes and change control boards: project governance →

Worth bringing in when: a project has quietly stopped moving; deadlines keep slipping by a fortnight at a time; your engineers and your stakeholders have stopped understanding each other; a regulated project needs its design controls, traceability and documentation set up so they hold up in an audit; or you need an outside read on whether a plan is sound before you commit budget.

Software & application development

Building the thing: applications for mobile, desktop and connected devices, and the services behind them. Android and Kotlin are home ground — Jetpack Compose, offline-first data, background sync, the real behaviour of a phone with no signal in a basement — with Windows applications, backend and cross-platform work alongside as the project needs.

For medical device software it is built to IEC 62304 from the first line: a software development plan, requirements and architecture traced to each other and to the risks, the safety class deciding how much rigour each part gets, unit and integration verification with recorded results, third-party software (SOUP) under control, and every anomaly tracked to closure.

What tends to be underestimated is everything around the code: release signing, store or regulatory compliance, privacy declarations, crash reporting, and a test suite that fails for real reasons rather than decoratively. Those are part of the work, not an afterthought at the end.

Worth bringing in when: you need a product built properly the first time; medical device software has to be developed to IEC 62304, or brought up to it; an existing codebase needs someone senior to stabilise it; or you have an app that works in development and keeps failing in the hands of real users.

AI and LLM integration

A model is easy to demo and hard to depend on. The work is in the gap between those two: designing prompts that survive input real people type, deciding what happens when the model is slow, wrong, or unavailable, and being honest in the interface about what it cannot do.

It also means knowing the cost. Before you commit, you should be able to say what the model costs per user per month and which part of the request drives it — usually not the part people assume.

In a regulated product an AI feature goes through the same design controls as everything else: an intended use, requirements it can be verified against, risks analysed for a component that is not deterministic, and validation on data that represents the people who will use it.

Worth bringing in when: you have an AI feature that impresses in a demo and frustrates in production; you are deciding whether a model is the right tool at all; you need an AI feature that will stand up to a design review; or you need someone to work out what it will cost at scale before the decision is made.

How engagements work

Scope, rates and timelines depend entirely on the work, so there is no price list here. Describe the problem and you will get a straight answer about whether I am the right person for it.