We engineer medical device software under IEC 62304 (Class A/B/C) with a documented software lifecycle suitable for FDA 510(k) and EU MDR submissions. Connected devices, SaMD, firmware, and the documentation regulators actually want to read.
A device team can ship software fast. They cannot ship software fast AND survive an FDA inspection unless the lifecycle, traceability, and risk management were designed in from day one. Trying to retrofit a regulatory file onto an agile codebase is where most device programs lose the year.
Software safety classification first. Risk management to ISO 14971. Traceability matrix from requirements → design → code → test, maintained in tooling that the auditors will accept. Verification and validation as part of the SDLC, not an end-of-project event.
FDA 510(k) submission packages organised and reviewed; EU MDR technical files structured to Annex II; post-market surveillance plan in place; deviations documented; SaMD apps built and approved on the same cadence as commercial software.
Class A/B/C lifecycle implementation — software safety classification, planning, requirements, architecture, V&V, configuration management.
Risk analysis, FMEA, hazard identification, and traceability — integrated with the software development process.
Polarion, Jama, or equivalent — set up and run to produce traceability matrices auditors accept.
Pre-submission preparation, predicate-device analysis, software documentation, and inspection-readiness reviews.
Technical files structured to Annex II, post-market surveillance plans, EUDAMED-aligned reporting.
Embedded firmware (C/C++/Rust), BLE/LoRa connectivity, secure boot, OTA updates, and device-management backends.