From Idea to Medical Device Software: A Realistic Timeline

Why "We'll Ship an MVP in Six Weeks" Doesn't Survive Contact With IEC 62304

Every first-time medical device software founder arrives with a consumer-software mental model: scope an MVP, ship it in six to eight weeks, iterate from user feedback. That model assumes you can change the product after it's in users' hands without re-certifying it. Medical device software under IEC 62304, the international standard for the software development lifecycle of medical device software, doesn't work that way — the lifecycle, the documentation, and the traceability requirements are baked into the build from week one, not applied afterward.

The earliest regulatory anchor is the intended-use statement: a precise description of what the software does, for whom, and in what clinical context. That single paragraph determines the FDA risk classification, which in turn determines how much process rigor the rest of the build has to carry. Teams that treat the design and development file as a thing to assemble later, once the code mostly works, pay for it twice — once building the software, and again retrofitting six months of undocumented decisions into a traceable record a reviewer can actually follow. Most of the timeline blowups later in this article trace back to exactly that mistake: treating the regulated build as a bolt-on to a generic dev process, rather than designing traceability and QMS alignment in from day one — exactly the kind of discipline an experienced software development partner should already have built into its process.

Opening the design history file in week one, alongside the first line of code, isn't bureaucratic overhead. It's the cheapest insurance against the two failure modes that eat the most calendar time later: retrofitted traceability and a classification that was never actually locked down.

How Long Does Medical Device Software Actually Take, by Risk Class?

This table is the direct answer, and it's the one none of the major guides on this topic give you cleanly: a month range per software safety class, for the build phase only. Treat these as planning ranges, not guarantees — scope, team experience, and integration complexity all move the number within the range.

Safety class	Typical profile	Build timeline	Process overhead
Class A	No injury possible if software fails (e.g. administrative/reporting tools, low-risk SaMD)	4–6 months	Lightest — minimal risk-management documentation
Class B	Non-serious injury possible (diagnostic-support tools, clinical integrations)	8–12 months	Moderate — formal risk analysis, unit + integration verification evidence
Class C	Death or serious injury possible (life-supporting or life-sustaining software)	14–24+ months	Heaviest — full ISO 14971 risk management, exhaustive traceability, independent verification

Two things routinely surprise founders about this table. First, the jump from Class B to Class C isn't linear — it's closer to doubling, because the verification and documentation burden scales with consequence severity, not with code complexity. Second, these ranges cover the build only. The next sections walk through what happens phase by phase inside that window, and then where the separate regulatory-review clock fits around it.

Phase 1 — Concept and Feasibility (Weeks 1–8)

This phase produces the intended-use statement, a technical feasibility assessment, and an early classification hypothesis — not final, but precise enough to shape every downstream decision. Teams that rush this phase to "start building faster" tend to lock in architecture choices that the real classification later contradicts, forcing rework in Phase 3.

The output that matters most here is a one-paragraph intended-use statement that a regulatory reviewer, not just your engineering team, would recognize as unambiguous. Vague intended use is the single most common reason classification gets revisited mid-build.

Phase 2 — Requirements and Risk Classification (Weeks 6–14, Overlaps Phase 1)

The Software Requirements Specification gets written here, and the classification hypothesis from Phase 1 gets tested against it: does the actual feature set match the risk profile you assumed? This is also where the depth of ISO 14971 risk-based analysis gets decided — a Class A tool needs a lighter risk file than a Class C one, and guessing wrong here means redoing risk analysis later at a much higher cost.

By the end of this phase, the class should be locked, not provisional. Everything downstream — how much verification evidence you need, how the architecture handles failure modes, how long Phase 5 testing will run — depends on that number being final.

Phase 3 — Architecture and Design (Months 2–4)

Software architecture decisions made here either save or cost months later, particularly around two things: SOUP (software of unknown provenance — third-party libraries, frameworks, and components you didn't write) and interoperability. Every SOUP component needs its own risk assessment and version-control discipline; discovering a critical dependency wasn't properly vetted during Phase 5 testing is one of the most common causes of late-stage schedule slips.

Interoperability — FHIR or HL7 connections to EHRs, labs, or monitoring systems — belongs in this phase's architecture, not bolted on after the core product works. Designing the data model and integration boundaries up front is materially cheaper than retrofitting an interface layer onto a system that assumed it would never need to talk to anything else.

Phase 4 — Implementation and Unit Verification (Months 3–8, Runs Alongside QMS)

Implementation under IEC 62304 can absolutely run in agile sprints — the standard doesn't mandate waterfall — but every sprint needs an evidence trail: unit tests mapped to requirements, code review records, and traceability maintained continuously rather than reconstructed at the end. Teams that treat documentation as a sprint-zero or post-launch task are the ones who end up spending weeks before submission trying to remember why a decision was made six months earlier.

The practical rule: if a reviewer asked "show me the evidence this requirement was verified" on any given Friday, you should be able to answer within the hour, not within a week of digging through commit history.

Phase 5 — Integration, System Testing, and Validation (Last 1–3 Months Before Submission)

Verification and validation are often used interchangeably but answer different questions: verification confirms you built the software right (does it meet the specification), validation confirms you built the right software (does it meet the user's actual clinical need). Both are required, and both need documented evidence.

Testing proceeds in levels — unit, integration, system, and acceptance — each building on the evidence from the one before. Skipping or compressing a level to save time is the most common reason this phase runs long: gaps discovered at system testing often trace back to an integration-level issue that should have surfaced weeks earlier.

Phase 6 — Regulatory Submission and Release: a Separate Clock From the Build

This is the gap in almost every other guide on this topic: FDA review time is not simply added to the end of your build timeline like one more phase. It runs on its own clock, governed by the FDA's own guidance on the content of premarket submissions for device software functions, and that clock can start partially in parallel with your own build — pre-submission meetings and documentation preparation don't have to wait for the last line of code.

What doesn't change is that submission-ready documentation is a build-phase deliverable, not a post-build scramble. A 510(k) or De Novo submission assembled from documentation that was maintained continuously through Phases 1–5 moves through internal review far faster than one assembled retroactively from scattered sources. Teams that plan regulatory counsel engagement as a late-Phase-4 activity, rather than a Phase-1 one, consistently lose weeks they didn't need to lose.

What Actually Blows Up the Timeline

Four failure modes account for most of the schedule slippage we see, and none of them are about the engineering being hard — they're about sequencing and discipline.

• Retrofitting traceability late. Rebuilding a requirements-to-test traceability matrix after the fact, instead of maintaining it continuously, routinely adds weeks right before submission — exactly when there's no slack left.
• SOUP and legacy-system integration surprises. A third-party component or legacy EHR interface that wasn't properly vetted in Phase 3 surfaces its problems during Phase 5 testing, when fixing it costs far more than it would have in design.
• Multi-stakeholder handoff delays. Clinical reviewers, regulatory counsel, and engineering rarely sit in the same room on the same cadence — a review that should take two days stretches to two weeks when it's waiting in someone's inbox.
• Deferring security and cyber review to the end. Cybersecurity documentation requirements have grown significantly in recent FDA guidance; treating it as a final checklist item instead of a design input invites last-minute architecture changes.

A Realistic Planning Checklist Before You Start the Clock

This isn't a generic QMS checklist — it's the short list of things that, done before Phase 1 formally starts, prevent the delays described above.

1. Draft the intended-use statement in precise, reviewer-legible language — not marketing copy.
2. Set an early classification hypothesis (A/B/C) and name who will confirm it formally by end of Phase 2.
3. Open the design history file on day one, not when documentation "becomes necessary."
4. Start a SOUP inventory before architecture is finalized, not after implementation begins.
5. Map every planned integration dependency (EHR, lab, monitoring system) before committing to an architecture.
6. Schedule a recurring review cadence with regulatory counsel starting in Phase 1, not Phase 4.

FAQ

How long does it take to build Class A SaMD?

Typically 4–6 months for the build phase, assuming the intended-use statement and classification are locked early and the process overhead stays proportionate to the low risk profile. Scope creep or a mid-build reclassification can extend this significantly.

Does FDA review time count against the development timeline?

No — it's a separate, partially-parallel clock. Build timelines in the table above cover development only; FDA review of a completed submission happens on its own schedule, though pre-submission activity can start before the build is finished.

Can regulatory prep run in parallel with development?

Yes, and it should. Pre-submission meetings, documentation templates, and early regulatory counsel engagement can all start during Phase 1–2 rather than waiting for a finished product, which shortens the effective end-to-end timeline considerably.

What's the single biggest cause of medical device software timeline slippage?

Retrofitting traceability that wasn't maintained continuously. It's a documentation problem dressed up as a schedule problem, and it almost always surfaces in the final weeks before submission, when there's no time left to absorb it.

Do agile sprints work under IEC 62304?

Yes. The standard doesn't mandate waterfall — it mandates evidence. Agile sprints work fine as long as every sprint produces the traceable evidence (requirements links, test results, review records) that a reviewer would need later.

How much longer does FHIR/HL7 interoperability add to the timeline?

Designed into the architecture from Phase 3, interoperability adds weeks, not months, to the schedule. Bolted on after the core product is built, it can add months — the cost difference comes from when the integration boundary gets designed, not whether it's needed.

When should the design history file be opened?

Day one of Phase 1, alongside the intended-use statement. Opening it later means reconstructing early decisions from memory and scattered artifacts instead of capturing them as they happen.