IEC 62304 for Startups: The Selective Compliance Approach That Gets You to MVP Without Killing Your Timeline

Four months into a health app build, a hospital procurement checklist lands in your inbox asking for evidence of IEC 62304 conformity. Someone on the team Googles IEC 62304 compliance startup MVP, and the first page serves up design history files, CAPA, and full quality management systems. By next morning’s standup, the working theory is that compliance means a 6-month side project running parallel to the actual product.

That theory fails on one detail: the standard scales its documentation burden by software safety class. Most early-stage digital health products land in Class B, and a Class B posture fits inside the agile workflow you’re already running.

There’s a market reason to get this right, too. FDA formally recognizes IEC 62304, and a declaration of conformity in a 510(k) or De Novo is the cleanest documented path to satisfying FDA’s software documentation expectations.

So this post does 4 jobs: settle your class, hand you the artifact table, show you the concurrent-documentation workflow, and leave you with a go/no-go checklist.

Does a startup really have to do full IEC 62304 compliance to ship a health app?

No. IEC 62304 scales its documentation by software safety class, and most early-stage digital health products are Class B, which fits inside an agile workflow. Build the records concurrently from sprint one and the compliance package comes together as a byproduct of the work you’re already doing.

Key Takeaways:

1. 62304 compliance is a documentation discipline you run alongside the build. Started in the first sprint, it adds hours per sprint instead of the months it costs when you reconstruct everything after the code is frozen.
2. Class B gives most early-stage SaMD a defined, manageable scope. The artifacts it requires are what a well-run engineering team already produces: requirements, architecture, test plans, release records. 62304 adds version control, traceability, and lifecycle maintenance on top.
3. Start the moment compliance becomes a requirement, and never backdate. Build the SOUP list from your first dependency, and archive test runs and artifacts per release as you go. Commit history makes reconstruction detectable, so the package has to build in real time.

Table of Contents

1. What IEC 62304 actually is (and what it doesn’t require)
2. Software safety class: the one decision that sets your entire documentation
3. The minimum required artifacts by class (straight from Table A.1)
4. Selective compliance: what can wait until Series B and what can’t wait a single sprint
5. Building 62304 into an agile workflow without stopping development
6. The Class B compliance checklist for an MVP SaMD: go or no-go for FDA pre-sub or procurement
7. Where RA consultants earn their fee (and where your team doesn’t need them)
8. Topflight Apps builds the 62304 record from sprint one, so there’s no catch-up sprint

What IEC 62304 actually is (and what it doesn’t require)

IEC 62304 is the international medical device software lifecycle standard. It governs the software development lifecycle (SDLC) for medical device software (MDSW) in both shapes: code embedded in a device, and code that is itself the device, what the IMDRF SaMD guidance calls Software as a Medical Device (SaMD).

The current version is IEC 62304:2006/AMD1:2015, still the version FDA recognizes and the one the EU harmonizes against. Specifically, it’s an FDA recognized consensus standard, listed in the FDA recognition database, which is why a declaration of conformity does real evidentiary work in a submission. The agency doesn’t mandate the standard, though: conformity gets demonstrated through process documentation and lifecycle records, and those records are what a reviewer actually reads.

IEC 62304 is not a quality management system (QMS), and conforming to it doesn’t require running one. There’s no quality manual in it, no CAPA process, no management reviews, no internal audits. That machinery lives in ISO 13485, which FDA folded into 21 CFR Part 820 through the QMSR. A startup without a full QMS can still be 62304-conformant.

62304 is one layer in the broader health app regulatory compliance stack. Inside that layer, nearly everything you’ll owe traces back to a single decision: the software safety class.

Software safety class: the one decision that sets your entire documentation burden

Every documentation requirement keys off one input: the IEC 62304 software safety class. The standard treats device code as safety-related software and sorts it by the worst harm a failure could cause.

How the class gets assigned (and when it can legitimately drop)

You assign the class with hazard identification against the intended use, then take the worst credible outcome of a software failure as your input. The standard assumes the code fails and grades what happens next. The IEC 62304 amendment (AMD1) sharpened the math: classification weighs harm severity and the probability of harm following the failure, while the probability of the failure itself stays out of the calculation. Worst credible case, every time, even when the average case looks benign.

There’s a legitimate way down. A risk control measure sitting outside the software (hardware interlocks, a clinician reviewing every output before it reaches care) can lower the class, provided the control is real and documented in your ISO 14971 risk management file. The class then reflects residual risk rather than raw hazard, which is the formal basis for clinician review as a safety barrier. Use it straight. The downgrade is the first thing a reviewer pokes, and Edition 2 exists partly because teams gamed it.

Where real digital health products land

Map the rule onto products you’d recognize:

• Aggregated wellness trends with no clinical output: a failure annoys a dashboard and hurts no one. Likely Class A.
• A remote monitoring display where a stale reading could delay a clinical response: likely Class B, the same harm logic that decides when an RPM app becomes a medical device.
• A neuro symptom tracker feeding clinician review, the shape at the center of Parkinson’s care app development: likely Class B, with the clinician as the external barrier.
• Dosing guidance in a pharma companion app, critical-value alerting, software controlling drug delivery: Class C.

We’ve sat on the building side of this call. The deep learning algorithm at the core of an FDA-cleared non-invasive diagnostic device, computer vision trained and validated on tens of thousands of clinical records, was ours. The pattern from that work: when the software’s failure mode is a missed detection of a serious condition, you’re not having a Class A conversation.

Run the software risk classification honestly and most early-stage SaMD lands in Class B: symptom trackers, clinical documentation tools, patient engagement, monitoring with clinician review as the barrier. If your true worst case reads Class C, line up regulatory help before development starts (more on that below).

⚠ Calling a Class B product Class A is the fastest credibility kill in a review. It reads as a team that skipped the risk analysis, or ran it and looked away. And don’t map 62304 classes onto FDA’s documentation levels: 62304 counts external risk controls, FDA’s Basic-versus-Enhanced call comes before them, so a legitimate Class B can still owe Enhanced documentation.

Edition 2 merges B and C in late 2026. Your submission doesn’t care yet

The next edition is in final approval, with publication targeted for late 2026. Treat the date as a target: a prior revision attempt collapsed. Edition 2 folds three classes into two levels, Level I replacing Class A and Level II absorbing B and C, and software that implements a risk control measure lands in Level II regardless of external controls. None of it touches a 2026 submission. FDA recognition and EU harmonization lag publication, and the current version governs until they catch up. Class B discipline today is Level II discipline tomorrow.

The minimum required artifacts by class (straight from Table A.1)

Most summaries will tell you Class A is nearly free, a plan and a release record and you’re done. Table A.1 says otherwise. The table below is the artifact-by-class map rebuilt against AMD1’s Table A.1, with the governing clause on every row, so you can see exactly what your class owes before you scope a sprint around it.

Read down the Class A column and the myth falls apart. Requirements analysis, system testing, configuration management, problem resolution, and the maintenance process all bind Class A. Even your lightest-class product carries a real lifecycle workload.

Reading the table as a Class B startup

Here’s the honest relief in that Class B column. The standard decomposes your code into a software item (a structural piece of the system) and, at the finest grain, a software unit, and the lighter Class B obligations track that hierarchy. You owe no detailed unit-level design spec; clause 5.4 gives Class B only 5.4.1, where Class C carries the full detailed-design burden. Integration and system testing are structured but achievable inside a normal sprint. And the line that scares most teams, unit verification under 5.5.2, is gentler than it reads.

The standard makes you define the verification method and acceptance criteria yourself, and it stops short of mandating an automated unit-test suite. Documented code review against written criteria, or a static-analysis pass you keep the output of, satisfies 5.5.2 for Class B. Many engineering teams already do the review; the 62304 delta is writing down the criteria and keeping the record. That’s the pattern across this whole column. The artifacts are mostly what a disciplined team produces anyway, plus version control, a traceability matrix, and the discipline to archive them per release.

One more split worth seeing in the table: SOUP is two rows, not one. The inventory binds every class under 8.1.2. The SOUP risk analysis binds only Class B and C. So a Class B team owes both, and most teams discover the second one late.

SOUP and the SBOM: one inventory, two deliverables

SOUP, software of unknown provenance, is every third-party component you didn’t write and can’t fully verify. For a React Native or Next.js health app, that list runs long:

• the framework itself, plus every npm or pub package underneath it
• HealthKit, Firebase, Twilio, the Stripe SDK
• your cloud APIs
• any open-source ML model you pulled in, which carries its own AI in healthcare compliance weight

Building that inventory on day one takes minutes. Reconstructing it from a finished codebase takes weeks of package-lock.json archaeology.

The SBOM is the same component list wearing a regulatory hat. FD&C 524B made a software bill of materials statutory for cyber devices in March 2023, and FDA has had refuse-to-accept authority over submissions that lack one since October 2023. The required format is machine-readable: SPDX or CycloneDX. So your SOUP list and your SBOM are two exports of one inventory. Keep the component data in one place, add the risk and anomaly columns 62304 wants, and generate the SPDX or CycloneDX file when a submission needs it. One inventory feeds both deliverables, so you maintain it once.

These IEC 62304 SaMD requirements look heavier listed out than they feel in practice, once you see how much of the artifact set a working team already generates. What turns the list from hours into weeks is the order you do it in, which is the next section.

Selective compliance: what can wait until Series B and what can’t wait a single sprint

Think of this as a map of what the standard mandates versus what gets layered on later, drawn so you don’t cut a corner by accident. The difference matters, because the things you can legitimately defer and the things you can’t are separated by a clean line in Table A.1, and reading that line wrong is how teams either over-build before they need to or get caught short in a pre-sub.

What can’t wait a single sprint

Four obligations sit in the all-class clauses of Table A.1, which means they bind a Class A product and therefore bind everyone. They’re the floor of the standard, and each one costs far more to reconstruct than to maintain:

• SOUP identification (8.1.2). Start the inventory at your first dependency. A spreadsheet or a column in your tracker is enough on day one.
• Configuration management (clause 8). Git with a written branch-and-tag strategy. You almost certainly run Git already; the deliverable is documenting the strategy and tagging releases.
• Problem resolution (clause 9). One page describing how your existing bug tracker classifies and resolves issues. The process exists; write it down.
• Release records (5.8). One record per production release, listing the component versions that shipped.

None of these is a project. Together they’re maybe a few hours of setup and minutes per sprint to maintain. The cost is entirely in the order you do them: built in from sprint one, they’re nearly free, and reconstructed from a finished codebase, they’re the HIPAA compliant software development equivalent of a catch-up sprint nobody budgeted for. This floor is the selective 62304 compliance digital health founders keep asking about, the genuinely deferrable parts start above it.

What belongs to the QMS, not to 62304

Plenty of what gets filed under “62304 work” lives outside the standard entirely. CAPA, supplier qualification, management review records, and internal audit programs are quality management system scope, governed by ISO 13485, not by IEC 62304. A pre-Series B team can legitimately defer the full QMS build-out and still be 62304-conformant, which is the practical core of minimum viable compliance.

One regulatory note that changes the framing: as of February 2, 2026, FDA’s QMSR took effect, folding ISO 13485:2016 into 21 CFR Part 820 and collapsing the old Part 820 versus ISO 13485 split into a single regime. So the deferral bucket is now one named regime you take on when the time comes. The design history file goes the same way: it’s legacy QSR vocabulary, and the concept survives as ISO 13485 design and development documentation, which your 62304 conformity can precede rather than wait on.

Stay honest about what deferral buys you, though. A lightweight QMS today is a real build-out cost later; you’re sequencing the work to match your stage. For the Class C-only artifacts a higher-risk product would owe on top of all this, the Table A.1 map above already lays them out.

Building 62304 into an agile workflow without stopping development

The teams that struggle with 62304 almost always made the same scheduling error: they treated documentation as a phase that happens after the code is done. Concurrent documentation, generated as you build, costs a fraction of what reconstruction costs, and it produces records a reviewer actually trusts because the timestamps line up with the commit history. Here’s how the artifacts fall out of the agile development workflow you’re mostly already running.

Requirements and architecture as living documents

The standard asks for a software requirements specification, and it’s happy for that SRS to be a version-controlled document you update as the product moves. Treat requirements as version-controlled entries with a unique ID each, REQ-001 onward, sitting in the same repo or tracker as everything else. When a requirement changes, the version history captures the change. That history is your evidence.

The same logic carries the architecture. A Class B software design specification needs components, data flows, external interfaces, and the rationale behind the design decisions, and a maintained wiki page covers all four. Update it in the sprint where the architecture actually changes, not in a documentation sprint six months later. HIPAA and security requirements enter the SRS here too, written as requirements with their own REQ-IDs. That’s how HIPAA compliant software development gets captured while the architecture is still moving, as design decisions land.

SOUP as an annotated dependency manifest

Your SOUP list is your dependency manifest with a few extra columns. The package.json is the foundation; the 62304 layer is a parallel record, in a spreadsheet, a Notion database, or a purpose-built tool like Greenlight Guru or Qualio, that adds version, known anomalies, and your update-monitoring note to each entry.

We’ve shipped this exact shape. When we rebuilt the companion app for Joovv’s light-therapy devices, the SOUP reality was React Native running on iOS and Android, a BLE layer controlling both legacy and current hardware, HealthKit and Google Fit pulls, Amazon Cognito for auth, and a web portal handling firmware updates, plus every package sitting underneath all of that. That whole stack is SOUP, and maintained as a manifest from the first dependency it took minutes per sprint. v1 shipped in six months with that discipline running the entire time. Rebuild the same list after the fact and you’re into weeks of forensic work.

Traceability and test records out of tools you already run

Traceability turns out to be light once it lives in the tools you already run. The records come off four things you’ve mostly got wired already:

• Traceability: in Jira or Linear, link every REQ-XXX to at least one test case. The link graph is your traceability matrix, and it exports straight to submission evidence when a reviewer asks.
• Test execution: GitHub Actions or CircleCI already runs your suite on every push. Configure it to archive the run as a build artifact, tagged by release, and your continuous integration pipeline doubles as your verification record.
• Manual coverage: for what automation can’t reach, keep a short manual test checklist and archive the completed copy per release.
• Problem resolution: one page documenting how your existing bug tracker classifies severity and tracks issues to resolution.

The throughline across all of it is concurrent documentation, captured in flight, which is the whole answer to how to comply with IEC 62304 without slowing development. The agile cadence and the compliance record come off the same set of tools, and a capable team of healthcare app developers builds the habit once and stops thinking about it.

⚠ The retroactive documentation trap. Backdating is detectable, and reviewers know exactly where to look. Commit history and file timestamps tell the real story, so a requirements doc that implies it predates the code it describes is a credibility problem the moment someone diffs the dates. Start the practice the sprint compliance becomes a requirement. Don’t reconstruct, don’t backdate, and never author a record meant to look older than it is.

The Class B compliance checklist for an MVP SaMD: go or no-go for FDA pre-sub or procurement

You’re ready for an FDA pre-sub or a procurement review when every block below checks. Run it as a go/no-go: a gap in any one of these is a gap a reviewer will find, so close it before you submit, not after they flag it.

Software development plan. Exists, version-controlled, with the class assignment justified against your ISO 14971 risk analysis and the lifecycle activities and roles defined.

Software requirements specification. Every requirement carries a unique REQ ID. Functional and non-functional requirements are both captured, and HIPAA and security live in here with their own REQ IDs, written like every other requirement.

Architecture. Components, data flows, external interfaces, and the rationale behind each significant design decision are all documented in one place.

SOUP. Complete list with versions, known anomalies pulled from release notes and CVE databases, and a documented process for monitoring updates. Your SBOM is generated or derivable from the same inventory.

Testing. Test plan references REQ IDs. Unit verification records exist per your documented Class B method, integration and system test records are archived by release, and traceability from requirement to test is complete.

Release. One record per production release, capturing the exact component versions that shipped.

Configuration management. Git with a documented branch strategy and tagged releases.

Problem resolution. A one-page documented process, backed by a bug tracker that classifies severity on every open issue.

Run this list before any external conversation and you’ll know where you stand in ten minutes. Treated as a standing reference, it doubles as a 62304 framework for an early-stage health app: the same boxes that clear a pre-sub are the ones that hold up when a hospital’s procurement team asks for evidence. Keep it current as the product moves, and you’ll have your readiness answer ready on any given day.

Where RA consultants earn their fee (and where your team doesn’t need them)

Bring RA in twice for Class B, and from day one for Class C. That’s the short version, and for most early-stage teams it’s the whole answer.

For a Class B product heading toward a 510(k) submission, two moments are worth paying an external regulatory consultant for. At the start, to validate the class assignment and structure the development plan so the documentation lines up with what a reviewer expects. And again before submission, for a gap review of the package against the predicate device and premarket notification requirements. Between those two points, a capable engineering team maintains the artifacts on its own, and ongoing RA retainer spend mostly buys you reassurance you don’t need.

Class C is a different call. Get external RA involved before development starts, because what Class C demands is genuinely hard to retrofit: unit-level verification rigor, detailed design, and complete traceability. Those are the things that show up as a common audit finding when teams try to backfill them. A De Novo classification or a tricky predicate story compounds that. If you’re taking on medical device companion app development and you’re not sure which class you’re in, that’s the conversation to have first.

Topflight Apps builds the 62304 record from sprint one, so there’s no catch-up sprint

We build the compliance record into the lifecycle from the first sprint. The requirements specification, the SOUP inventory, and the traceability links all start with the earliest code and grow with the product. By the time you need the documentation package, it’s already there, which is the whole reason 62304 doesn’t have to derail a timeline.

We’ve done this on real devices. We rebuilt the companion app for Joovv’s light-therapy hardware with IEC 62304 in scope from the start, BLE control, HealthKit and Google Fit integration, firmware management, the full stack documented as it shipped. And the deep-learning algorithm at the core of an FDA-cleared diagnostic device was ours, built to the verification and traceability rigor that clearance demands. Joovv and the diagnostic device sat in different risk classes, and we held both to the same discipline.

If you’re building a SaMD product and you need a compliant development process that keeps your sprints moving, talk to us before you schedule the documentation catch-up sprint, because there shouldn’t have to be one. We run IEC 62304 agile development as the default. The records build alongside the code, so when a reviewer asks, the package is already submission-ready.