Most early-stage medical device teams aren't ready to file a submission, and don't need a full quality system on day one. But the engineering decisions made in month two are what determine whether month fourteen's compliance push is a formality or a rebuild. Here's what that looks like in practice.
There's a real tension in early medical device development: a startup building its first prototype usually can't justify a full ISO 13485 quality management system, a dedicated regulatory affairs hire, and formal design controls before it even knows the product works. But waiting until a submission is imminent to start thinking about IEC 62304 and ISO 14971 means retrofitting process onto a codebase and a risk posture that were never built with it in mind — which is slower and more expensive than building it in from the start. A competent engineering partner's job in that gap is to keep the door open: build in a way that doesn't foreclose the compliance path, without pretending the startup already has a QMS it doesn't need yet. This describes engineering practice, not a substitute for regulatory/quality expertise — a real quality function still has to own the formal process when the time comes. For the broader regulatory picture this sits inside, see our note on regulatory basics for connected medical devices.
IEC 62304 ultimately asks for traceability: a line from documented requirement, to design, to implementation, to verification evidence. A team that writes requirements down as they're decided — even informally, in an issue tracker or a lightweight requirements doc, rather than in someone's head or a Slack thread — is doing 80% of the hard part of that traceability before it's ever asked for formally. The habit that matters isn't the tooling, it's the discipline: every non-trivial design decision (why this sensor sampling rate, why this fail-safe behavior, why this state machine) gets written down with its rationale at the time it's made, not reconstructed from memory a year later when a reviewer asks.
As covered in our note on IEC 62304 software safety classification, the classification a software item eventually receives (A, B, or C) determines how much rigor its documentation and verification need. A partner thinking ahead of the formal classification exercise will still separate code that could plausibly touch a safety-relevant function (sensor data processing, alarm logic, dosing or actuation control) from code that clearly can't (UI rendering, Bluetooth pairing flow, analytics). That separation — clean interfaces, minimal coupling — costs little extra effort when it's designed in from the start, and it means that when classification does happen formally, the higher-rigor requirements land on a bounded, identifiable part of the codebase instead of the whole system.
ISO 14971 risk management doesn't require a finished, board-approved risk management file to be useful early — it requires the habit of asking, for every significant feature or failure mode under consideration, "what's the worst plausible outcome if this goes wrong, and what would catch it." A partner who raises that question naturally during design reviews (what happens if the sensor gives an implausible reading, what happens if connectivity drops mid-measurement, what happens if firmware update is interrupted) is doing real risk analysis, even if it isn't yet formatted as a formal risk file. This kind of failure-mode-first thinking is exactly what we cover in our note on fail-safe design for medical wearables. Capturing those discussions as they happen — even in engineering notes — means there's a real trail to formalize later, instead of a blank page and a memory exercise.
Both standards eventually expect a manufacturer to be able to answer "what changed, when, why, and what was re-verified as a result" for any given release. That's a much smaller lift if the engineering team's normal git discipline — meaningful commit messages tied to tracked issues, tagged releases, a changelog that says why something changed and not just what — was already solid practice before anyone was thinking about a QMS. Retrofitting a clean history onto a year of undocumented commits, by contrast, is close to impossible; at best, a team ends up documenting the current state and drawing a line under everything before it. See our note on version control and change management for hardware for the broader discipline this connects to on the hardware side.
Every RTOS, communication stack, and open-source library pulled into the firmware is Software of Unknown Provenance in the eyes of IEC 62304, and eventually needs to be inventoried and risk-assessed. Keeping a running, accurate dependency manifest from the start — rather than discovering mid-submission that nobody can say with confidence which version of which TLS library actually shipped in which firmware revision — is one of the cheapest habits to build early and one of the most expensive to reconstruct late. It also directly feeds the SBOM (Software Bill of Materials) FDA now expects in cybersecurity documentation; see our note on FDA cybersecurity requirements and SBOMs for that side of it.
None of this means an early-stage team should act as if it already has a certified quality system — that would slow down the exploration a young product genuinely needs. It means the engineering habits — written-down requirements with rationale, architectural separation by safety relevance, risk questions asked at design time, disciplined version history, and honest dependency tracking — cost little to build in early and are extraordinarily expensive to retrofit. That's the difference between a compliance push that's mostly formalization of existing practice and one that's a rebuild against a deadline. We build embedded systems and firmware for regulated devices with that discipline from the first sprint — see our firmware work and embedded hardware work for how this fits into a full engagement, and our medical device development work for how it applies specifically to regulated health products.
