Before your med-tech startup writes a single line of code, you need a regulatory strategy. This guide covers FDA 510(k) clearance, SaMD classification, IEC 62304, design controls, risk management, and the documentation that makes or breaks a submission.
Most med-tech founders think about FDA clearance as something that happens at the end of development — a box to tick once the product is built. That assumption is one of the most expensive mistakes a startup can make. FDA 510(k) clearance is not a post-development audit. It is a process that must be woven into your software architecture, your development workflow, and your team's daily practices from the very first sprint.
If your software is classified as a Software as a Medical Device (SaMD), every decision you make during development — your version control practices, your testing protocols, your change management process — becomes regulatory evidence. The FDA will review it. Investors will ask about it. And if you have not built it correctly from the start, you will be rebuilding it from scratch at the worst possible time.
This guide is written for founders, CTOs, and lead developers at med-tech startups who want to understand what FDA-ready software development actually looks like before a single line of code is committed.
A 510(k) submission is a premarket notification to the FDA demonstrating that your device is at least as safe and effective as a legally marketed predicate device — one that was already cleared or approved before 1976, or that has itself received 510(k) clearance. This is the most common pathway for medical devices, including software-based ones, that do not require the more intensive Premarket Approval (PMA) process.
The name comes from Section 510(k) of the Federal Food, Drug, and Cosmetic Act. Clearance — not approval — is the correct term. The FDA is not endorsing your device; it is confirming that your substantial equivalence argument is sound and that your device meets applicable safety standards.
To establish substantial equivalence, your submission must demonstrate that your device has the same intended use as the predicate device, and either the same technological characteristics, or different technological characteristics that do not raise new questions of safety and effectiveness.
Finding the right predicate is a strategic decision that shapes your entire regulatory argument. The wrong predicate can force you into a higher risk classification, require additional clinical data, or trigger FDA questions that delay your clearance by months. This predicate search should happen before architecture decisions are made.
Not all health-related software requires FDA clearance. The FDA distinguishes between software that is a medical device and software that supports healthcare administration or general wellness. Getting this classification wrong in either direction is costly — treating non-regulated software as regulated wastes resources, while shipping regulated software without clearance exposes your company to enforcement action.
Software as a Medical Device (SaMD) is defined by the International Medical Device Regulators Forum (IMDRF) — and adopted by the FDA — as software intended to be used for one or more medical purposes without being part of a hardware medical device. If your software is intended to diagnose, treat, mitigate, or prevent disease or condition, it is almost certainly SaMD.
The FDA's 2019 guidance on Policy for Device Software Functions and Mobile Medical Applications clarified that software functions intended only for administrative support, general wellness, or electronic health records are generally outside device regulation. But the moment your software makes or informs a clinical decision, the picture changes rapidly.
If you are unsure whether your software qualifies as SaMD, engage a regulatory consultant before writing a single requirement. The classification determines everything that follows.
FDA-cleared medical software must comply with a set of interlocking standards and regulations. Three are fundamental to any 510(k) software submission.
IEC 62304 is the international standard that defines the lifecycle processes required for medical device software. The FDA references it extensively in its software guidance and expects to see evidence of compliance in 510(k) submissions. It covers software development planning, requirements, architecture, detailed design, unit implementation, integration and testing, system testing, release, and maintenance.
IEC 62304 introduces three software safety classes — A, B, and C — based on the severity of potential harm if the software fails:
| Safety Class | Harm Potential | Documentation Burden |
|---|---|---|
| Class A | No injury or damage to health possible | Lowest |
| Class B | Non-serious injury possible | Moderate |
| Class C | Death or serious injury possible | Highest |
Most diagnostic and therapeutic SaMD falls into Class B or Class C, which requires full documentation of your software architecture, unit-level testing, and a comprehensive software development plan. Building this retroactively is painful and expensive. Building it from sprint one is simply good engineering discipline.
ISO 14971 is the standard for risk management applied to medical devices, and software is no exception. It requires you to identify hazards, estimate and evaluate associated risks, implement risk controls, and monitor the effectiveness of those controls throughout the product lifecycle.
For software, this translates into a living risk management file that traces every identified hazard through to its mitigation measure. Your risk management activities must be integrated with your development process — when a new feature is added, risk analysis must be updated. When a bug is found in production, its risk implications must be assessed before the patch is shipped.
21 CFR Part 820 — the FDA's Quality System Regulation (QSR), now being harmonised with ISO 13485 — governs how medical device manufacturers design, manufacture, and control their products. For software companies, the most relevant provisions are the design control requirements in Part 820.30, which mandate documented design inputs, design outputs, design reviews, design verification, design validation, and design transfer processes.
If your software development process is not compliant with 21 CFR Part 820, the FDA can — and does — issue warning letters that halt commercialisation. This regulation is not aspirational; it is enforceable.
Design controls are the systematic process by which you document, review, and verify that your software meets its intended use. Under 21 CFR Part 820.30, they are mandatory for Class II and Class III devices — which covers the overwhelming majority of SaMD requiring 510(k) clearance.
Design inputs are the physical and performance requirements of your device — the functional, performance, safety, and regulatory requirements that the finished software must satisfy. They must be documented in a controlled manner, reviewed and approved, and traceable throughout the development process.
Design outputs are the results of each design phase — specifications, source code, test protocols, user documentation — that together define your finished device. Each output must be traceable back to the design inputs it satisfies. This traceability is what the FDA examines when it reviews your submission.
Design verification confirms that your design outputs meet your design inputs — that the software you built satisfies its specifications. This is primarily accomplished through unit testing, integration testing, and system testing, all of which must be documented with traceable test protocols and results.
Design validation is different and often misunderstood. Validation confirms that your finished device meets the needs of the intended user in the intended use environment. It typically involves usability testing with representative end users — clinicians, patients, or both — and must be performed on a device that is substantially equivalent to the final production version.
A requirements traceability matrix (RTM) is not optional for FDA submissions — it is expected. The RTM maps every user need to a design input, every design input to a design output, and every design output to a verification or validation activity. It is the document that proves your development process was controlled and systematic. Build it from the start; maintaining it retroactively across hundreds of requirements is a significant undertaking.
Risk management for SaMD is an ongoing engineering activity, not a one-time document. ISO 14971 requires a systematic process that begins during concept development and continues through post-market surveillance.
Start by systematically identifying every way your software could contribute to patient harm. For diagnostic software, consider what happens when the algorithm produces a false positive or false negative. For therapy-controlling software, consider the consequences of an incorrect dosage recommendation, a delayed alert, or a communication failure between system components.
Hazard identification should involve clinicians and end users, not just engineers. The people who use medical software in clinical settings see failure modes that developers rarely anticipate.
For every identified hazard with unacceptable risk, you must implement a risk control — a design change, a warning, a physical safeguard, or a combination — and document its effectiveness. After controls are applied, the residual risk must be acceptable, either on its own or in the context of the overall risk-benefit analysis of your device.
The FDA expects to see this analysis in your submission. Reviewers will ask: what are the risks, what did you do about them, and how do you know your controls work?
The FDA's 2023 final guidance on Cybersecurity in Medical Devices — backed by the Consolidated Appropriations Act of 2023 — made cybersecurity documentation a mandatory component of 510(k) submissions. The FDA can now refuse to accept submissions that do not include a cybersecurity plan. This is not a future concern; it is a present requirement.
Your submission must include a Software Bill of Materials (SBOM) — a complete inventory of every commercial, open-source, and off-the-shelf software component in your device. This allows the FDA and post-market surveillance systems to quickly assess your device's exposure when new vulnerabilities are disclosed.
The FDA's guidance emphasises a Secure Product Development Framework (SPDF) — the idea that security must be designed into the product architecture, not bolted on after the fact. This aligns directly with the design controls framework: security requirements are design inputs, and your security architecture is a design output that must be verified and validated.
A complete 510(k) software submission includes a specific set of documentation artefacts. The FDA's guidance document Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices defines the expected content based on the level of concern (Minor, Moderate, or Major) associated with your software.
For Moderate and Major level-of-concern software — which again covers most SaMD — expect to provide:
Having worked with multiple med-tech startups through the 510(k) process, the same mistakes appear repeatedly. Knowing them in advance is the fastest way to avoid them.
The most expensive mistake. Without a regulatory strategy — a defined intended use, a confirmed predicate device, a determined device classification, and a planned pathway — development decisions are made in a vacuum. Features get built that create new regulatory questions. Architectures get locked in that are incompatible with the safety class requirements. The rework required to retrofit compliance onto an uncompliant codebase routinely exceeds the original development investment.
In consumer software development, requirements evolve fluidly. In medical device development, every change to a requirement triggers a cascade of documentation updates — risk analysis, traceability matrix, test protocols, design review records. Without a formal change control process in place from the start, requirement changes accumulate without corresponding documentation updates, and by the time submission is being prepared, the traceability chain is broken in dozens of places.
The FDA's guidance on Applying Human Factors and Usability Engineering to Medical Devices is not optional reading. Use-related hazards — errors caused by the user interface, not software defects — are a leading cause of medical device incidents. Your usability engineering file must document formative and summative usability testing, use error analysis, and how your interface design mitigates identified use errors.
Modern software is built on open-source components, and those components have vulnerabilities. The FDA expects you to know exactly what is in your software and to have a plan for responding when vulnerabilities are disclosed in your dependencies. Building an accurate SBOM after the fact — especially for a product built without dependency discipline — is a significant undertaking.
Many med-tech startups do not have in-house expertise in FDA-regulated software development. That is not a disadvantage if you choose the right development partner. A partner who has built SaMD before will have templates for your Software Requirements Specification, your risk management file, your design history file, and your traceability matrix. They will structure your sprint ceremonies to generate the documentation artefacts the FDA expects. And they will flag regulatory implications of technical decisions before those decisions become technical debt.
When evaluating development partners for regulated software, ask specifically:
The right partner does not just write code — they help you build the evidentiary record that supports your submission.
The FDA's target review time for a standard 510(k) is 90 days from acceptance. However, total elapsed time from submission to clearance is typically 6–12 months when you account for FDA review, requests for additional information (which are very common), and response preparation. Complex submissions or those with significant cybersecurity or AI/ML components often take longer. Starting your regulatory documentation from day one of development is the single most effective way to compress this timeline.
A 510(k) requires a predicate device — an existing legally marketed device that your product is substantially equivalent to. If no appropriate predicate exists, the De Novo pathway allows you to request a new device classification for a novel low-to-moderate risk device. De Novo submissions take significantly longer and require more clinical and technical evidence, but a cleared De Novo device can itself serve as a predicate for future 510(k)s.
Yes. The FDA's Action Plan for AI/ML-Based Software as a Medical Device and subsequent guidance documents address the unique regulatory challenges of AI/ML — particularly adaptive algorithms that change their behaviour based on real-world data. The FDA is developing a framework for predetermined change control plans (PCCPs) that allows certain algorithm updates to be made post-clearance without a new submission, but this framework requires extensive pre-specification and algorithmic transparency documentation at the time of the original submission.
Yes. 21 CFR Part 820 requires that you have a Quality Management System (QMS) in place as a condition of FDA clearance. You do not need ISO 13485 certification (though it helps), but you do need documented procedures covering design controls, document control, change control, CAPA (corrective and preventive action), and complaint handling. Establishing your QMS early — and actually using it during development — means your Design History File is being built in real time rather than reconstructed at submission.
The FDA user fee for a standard 510(k) submission is set annually — in recent years it has been in the range of $20,000–$25,000 USD for standard applicants, with significant reductions for small businesses. The larger costs are internal: the regulatory consultant fees, the documentation preparation, the usability testing, and the time diverted from product development to submission preparation. Startups that build compliance into their development process from the start typically spend significantly less on submission preparation than those who retrofit it.
Last updated: September 2025
Get expert guidance on implementing AI solutions that actually work. Our team will help you design, build, and deploy custom automation tailored to your business needs.
AI is reshaping fintech—but building compliant, fast, and advisor-friendly financial products requires more than good models. This guide covers the regulatory landscape, architecture decisions, and UX principles that separate successful AI fintech products from costly failures.
Building AI into a healthcare product means navigating HIPAA from your first line of code. This guide covers what HIPAA actually requires of software, how to architect for compliance, and the common mistakes that expose startups to breach liability.
Offshore development has a reputation problem—but the failures are almost always structural, not geographical. This guide covers how to build a hybrid team that delivers enterprise-grade software reliably, regardless of where the developers sit.