Software as a Medical Device (SaMD) is software intended for a medical purpose, diagnosing, treating, or preventing disease, that is not part of a hardware device. The IMDRF defines the term and the FDA regulates it in the U.S. Whether your app is SaMD depends on its intended use, not its technology: a symptom checker that diagnoses is typically SaMD, while a wellness tracker usually is not. Building a SaMD MVP runs $60,000 to $200,000, and clearance pathways (510(k), De Novo, PMA) add cost and 3 to 18+ months of review.
What Software as a Medical Device actually is
SaMD is a category defined by the International Medical Device Regulators Forum (IMDRF) and adopted by the FDA: software intended to perform one or more medical purposes without being part of a physical medical device. The phrase that matters is "medical purpose", diagnosis, treatment, cure, mitigation, or prevention of disease. Software embedded in an MRI machine is not SaMD (it drives hardware); a standalone algorithm that reads images and flags a likely tumor is.
The decisive factor is intended use, which in regulatory terms is shaped largely by what you claim your product does. The same machine-learning model can be a regulated device or an unregulated wellness tool depending on whether you market it as "detects atrial fibrillation" or "shows your heart rate trends." Founders routinely underestimate this: the regulatory status follows your claims, so loose marketing copy can pull an otherwise-exempt app into device territory. If your product touches diagnosis or treatment, read this alongside FDA clearance for AI medical software, which goes deeper on the AI-specific review path.
When your app becomes a medical device
Your app becomes a regulated medical device the moment its intended use is to diagnose, treat, cure, mitigate, or prevent disease and no exemption applies. The table below contrasts common health-app behaviors that typically stay out of scope with those that usually pull you in.
| Behavior | Usually NOT a device | Usually IS a device (SaMD) |
|---|---|---|
| Symptom input | Logs symptoms for the user's reference | Outputs a diagnosis or condition likelihood |
| Fitness and wellness | Step counts, sleep trends, general fitness | Detects a specific arrhythmia or disease |
| Medication | Reminders and adherence tracking | Calculates a patient-specific dose |
| Imaging | Stores and displays images | Analyzes images to flag pathology |
| Decision support | Shows guidelines a clinician can independently review | Drives a treatment decision the clinician cannot verify |
That last row is the clinical-decision-support (CDS) line, and it is genuinely subtle. Software that gives a clinician information they can independently evaluate is often exempt; software the clinician must rely on without being able to check the basis is more likely a device. We unpack that boundary in clinical decision support software development. This is general information, not regulatory advice; the determination is fact-specific and you should engage qualified regulatory counsel.
IMDRF risk categories
The IMDRF classifies SaMD by combining two factors: the seriousness of the patient's condition (critical, serious, or non-serious) and the significance of the information the software provides to the healthcare decision (treat or diagnose, drive clinical management, or inform clinical management). The intersection yields four risk categories, I through IV, with IV being the highest risk.
| Category | Risk level | Example |
|---|---|---|
| I | Lowest | Informs management of a non-serious condition |
| II | Low-moderate | Drives management of a serious condition |
| III | Moderate-high | Diagnoses or treats a serious condition |
| IV | Highest | Diagnoses or treats a critical condition |
Higher categories demand more rigorous evidence, documentation, and oversight. The category does not map one-to-one to an FDA pathway, but it predicts how heavy your regulatory burden will be. Knowing your likely category early lets you plan the evidence you must gather, which is far cheaper to design in than to bolt on later.
FDA pathways: 510(k), De Novo, and PMA
In the U.S., most SaMD reaches market through one of three FDA pathways, chosen by risk class and whether a similar device already exists. The right pathway shapes your timeline, evidence, and cost more than any engineering decision.
- 510(k) clearance. For moderate-risk (Class II) devices that are "substantially equivalent" to an existing legally marketed device (a predicate). The most common path; review often runs 3 to 12 months after submission.
- De Novo. For novel low-to-moderate-risk devices with no predicate. It creates a new classification and can take 9 to 18 months, but opens the door for future 510(k)s to use you as a predicate.
- PMA (Premarket Approval). For high-risk (Class III) devices. The most demanding pathway, requiring clinical evidence and often over a year of review.
- Exempt. Some low-risk software is exempt from premarket submission, though it may still face general controls.
A common startup strategy is to launch the non-device portion of your product first, gather real-world usage and evidence, then enter the regulatory process for the clinical features with a stronger dossier. That sequencing keeps you generating signal while the long clearance clock runs. If your product is a digital therapeutic, the pathway and evidence expectations overlap heavily with our digital therapeutics development guide.
What SaMD development costs in 2026
SaMD economics split into two buckets: building the software and clearing it. The software MVP follows normal healthtech build costs; the regulatory pathway can equal or exceed that depending on class and evidence requirements.
| Component | Typical 2026 cost | What's included |
|---|---|---|
| SaMD MVP build | $60,000 - $200,000 | Core algorithm, app, HIPAA baseline, design controls and documentation |
| 510(k) pathway | +$30,000 - $150,000 | Regulatory consulting, testing, submission preparation |
| De Novo / PMA | +$150,000 and up | Clinical evidence, extensive documentation, longer review |
The cheapest move is to confirm whether your launch feature set even triggers device regulation before you spend on a regulatory pathway. Many viable products ship a non-device MVP first. For broader build economics, see healthcare app development cost and how much an AI MVP costs.
Building SaMD the right way
SaMD development demands more discipline than a typical app because the FDA expects design controls, risk management, and documented requirements traceability from the start. Quality processes (often aligned to ISO 13485 and IEC 62304) are not paperwork you generate at the end; they are how you build, so the evidence exists when you need it. Retrofitting them is painful and expensive.
If your SaMD uses AI, the bar rises further: you need to document training data, performance, and how the model behaves, and changes to a learning model raise their own regulatory questions. The FDA's framework for AI-enabled devices increasingly expects a predetermined change-control plan, a documented description of how the model may be updated within bounds without a new submission each time. Designing that flexibility in early saves you from re-clearing the product every time you retrain. Our building AI with patient data guide covers the data-handling side, and FDA clearance for AI medical software covers the AI-specific review expectations. This is general information, not regulatory or legal advice; engage qualified regulatory counsel and clinical advisors before making determinations.
Pre-submission strategy and lifecycle obligations
The smartest regulatory move for most SaMD startups is to engage the FDA early rather than at the end. The agency's Q-Submission (pre-submission) program lets you ask, before you build the full dossier, whether your intended use is a device, which classification applies, and what evidence the reviewers expect. A single pre-sub meeting can save you from gathering the wrong evidence for months, and it costs far less than a failed submission.
SaMD obligations also do not end at clearance. Once on market you carry lifecycle responsibilities: post-market surveillance, complaint handling, adverse-event reporting, cybersecurity maintenance, and change management for every update you ship. Software's rapid release cadence collides with device-grade change control, so you need a process that decides, for each change, whether it can ship under your existing clearance or requires a new submission. Treating your release pipeline as part of your quality system, rather than a separate engineering concern, is what keeps a fast-moving SaMD team compliant. The maturity of those internal processes is one of the things to probe when choosing a build partner, which we cover in choosing a healthtech software development company.
How SpeedMVPs builds SaMD-track products
SpeedMVPs is an AI MVP studio that ships production-ready, HIPAA-ready healthtech MVPs in 2 to 3 weeks with fixed pricing and direct developer access. For SaMD-track products, we help you ship the non-device portion of your product fast so you can validate demand and gather evidence, while building the algorithm and documentation in a way that does not box you out of a future regulatory path. We are an engineering partner, not your regulatory consultant, the FDA determination and submission belong to qualified regulatory counsel, but we make sure your codebase, data handling, and documentation support that process rather than fighting it.
For the full vertical context, our pillar guide on healthtech MVP development ties architecture, compliance, and AI together, and the AI healthcare MVP guide covers where AI can responsibly fit in regulated care.
Ready to scope your SaMD MVP?
If you are building software that may be a medical device and want to validate it without prematurely committing to a full regulatory program, let's scope it together. We'll help you ship the right first slice, build evidence cleanly, and give you a fixed price and timeline. Book a free discovery call to get started, or explore our AI MVP Development service. This is general information, not regulatory advice; consult qualified regulatory counsel for your specific situation.
