The feature is finished. Someone writes the App Store description, adds the sentence "detects early signs of sleep apnea," and your consumer wellness app has become, on paper, a medical device — without a single line of code changing.
This is the thing founders get wrong about FDA regulation of software. The agency does not regulate algorithms, sensors, or accuracy in the abstract. It regulates intended use, and intended use is established by what you claim: your marketing, your app store copy, your labeling, your sales deck, and statements your team makes publicly. The same model that outputs a number can be a wellness feature or a diagnostic device depending on the sentence next to it.
What follows is the decision framework, written structurally. It deliberately does not tell you your product's classification, because nobody can do that from a blog post and because a wrong answer here is expensive in a way an SEO article should not be casual about.
The statutory question, in plain terms
A product is a device under US law, broadly, if it is intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or any function of the body. Software can satisfy that definition on its own — the international term for it is Software as a Medical Device, or SaMD, meaning software intended for a medical purpose that performs that purpose without being part of a hardware medical device.
The 21st Century Cures Act narrowed this for software specifically, carving certain software functions out of the device definition. The carve-outs cover, broadly: administrative support for a healthcare facility; software intended for maintaining or encouraging a healthy lifestyle that is unrelated to diagnosis, cure, mitigation, prevention, or treatment; electronic health records meeting stated conditions; software for transferring, storing, or displaying data; and certain clinical decision support software where the clinician can independently review the basis for the recommendation.
That last one is where a lot of "AI copilot for clinicians" products live and where the analysis is genuinely difficult. If your product tells a clinician what to do and they cannot reasonably reconstruct why, the carve-out is unlikely to help you.
The general wellness lane
Separately from the statutory carve-outs, FDA has published a policy describing general wellness products it does not intend to regulate. The two-part shape of it is worth internalizing:
A general wellness product has an intended use that either:
- relates to maintaining or encouraging a general state of health or a healthy activity — sleep, fitness, relaxation, weight management, mental acuity, self-esteem — with no reference to diseases or conditions; or
- relates to the role of healthy lifestyle in helping reduce the risk or impact of certain chronic diseases or conditions, where it is well understood and generally accepted that healthy lifestyle choices may play a role in health outcomes.
And the product must be low risk — not invasive, not implanted, not involving an intervention or technology that raises safety questions if controls are not applied.
Both halves have to hold. A product with an impeccable wellness claim that lasers your skin is not in this lane. Neither is a low-risk app that claims to detect a condition.
Category-two claims are the subtle ones. "May help reduce the risk of cardiovascular disease as part of a healthy lifestyle" can sit inside the policy. "Reduces your risk of a heart attack" does not — it is a disease claim with a causal assertion behind it.
Where the line actually sits: claim pairs
The clearest way to teach this is to put near-identical claims side by side. The left column is generally consistent with a general-wellness posture; the right column reads as a device claim. The difference is rarely technical.
| Wellness framing | Device-shaped claim |
|---|---|
| "Track your heart rate during workouts" | "Detects atrial fibrillation" |
| "Understand your sleep patterns" | "Screens for sleep apnea" |
| "Log your mood and spot patterns" | "Identifies depressive episodes" |
| "Supports relaxation and stress management" | "Treats anxiety disorder" |
| "Helps you build consistent eating habits" | "Manages type 2 diabetes" |
| "Coaching to help you move more" | "Rehabilitation therapy for post-surgical recovery" |
| "Your readings, organized for your next appointment" | "Alerts you when your readings are dangerous" |
| "Form feedback on your squat" | "Corrects movement dysfunction to prevent injury" |
Read your own marketing site against that table. In our experience the engineering team is usually careful and the growth team is not, because the right column converts better. That gap is where most accidental device claims are born.
Three specific accelerants:
- The word "detect." It is a diagnostic verb. So are screen, diagnose, identify, monitor for, and alert to.
- Naming a condition. The moment a specific disease appears in your copy attached to your product's function, the general-wellness lane narrows sharply.
- Implying action. "Contact your doctor if the app shows X" builds a clinical workflow around your output, which is a strong signal about intended use.
Where the AI coach becomes a claim
Conversational AI in health products is the current version of this problem and it is harder than static copy, because the claim is generated at runtime.
Your marketing can be immaculate and your model can still tell a user their chest pain is probably muscular. You did not write that sentence; you shipped the system that produced it, and intended use analysis looks at what the product is designed and promoted to do — but a product that routinely produces diagnostic output is not easy to characterize as something else.
The engineering responses that matter:
- Constrain the output surface. Refusal and redirect behavior for symptom, diagnosis, medication, and dosage questions, tested as a product requirement rather than a prompt suggestion.
- Test adversarially and keep the evidence. A regression suite of prompts designed to elicit clinical claims, run every release, with results retained. This is both a safety control and documentation of intent.
- Escalation paths, especially for crisis content. Any mental-health-adjacent product needs a designed, tested route to human help and to emergency resources. This is a safety obligation independent of device status.
- Do not let personalization drift into prescription. "People with your training history often do X" is different from "you should take X."
If you are building an AI coach assistant or anything in mental health, scope those constraints as features with acceptance criteria. They are the difference between a defensible product and a demo. If you want them written as testable requirements rather than good intentions, that is a thing we do.
If you are a device: the shape of the path
This section is deliberately structural. Do not assume any of it applies to you without a regulatory specialist.
US devices are grouped into three classes by the level of control needed to provide reasonable assurance of safety and effectiveness. Class I is lowest risk with general controls; Class II typically requires special controls and, most commonly, a premarket notification demonstrating substantial equivalence to an existing legally marketed device; Class III is highest risk and generally requires premarket approval with clinical evidence. Where a novel device is low-to-moderate risk but has no predicate to compare against, a separate pathway exists to classify it.
What that means for a software company, practically:
- Quality system. Design controls, documented requirements and traceability, verification and validation, risk management, and change control become mandatory process, not good practice.
- Evidence. Depending on the claim, clinical or analytical validation data. This is where budgets and timelines change by an order of magnitude.
- Cybersecurity documentation. Premarket cybersecurity expectations for connected devices are now substantial and specific.
- Change management. Shipping weekly stops being straightforward. For AI-enabled products there is an established mechanism for pre-specifying planned model changes so that not every update requires a new submission.
- Post-market obligations. Complaint handling, adverse event reporting, and corrections and removals.
Timelines and costs here are not something to estimate in a blog post. What is safe to say: this is a different company than a consumer wellness app, with a different funding profile and a different hiring plan, and founders who discover it late usually discover it at the worst possible moment.
The strategy most founders should actually run
The instinct when you find this line is to either ignore it or to freeze. The better move is a deliberate two-stage plan.
Stage one: ship the narrow product. Build the version whose claims sit comfortably inside general wellness. Track, log, visualize, coach on behavior, organize information for the user's own doctor. Get real users, real retention data, and real evidence that the underlying signal is good. Almost every claim you eventually want to make will need that evidence anyway.
Stage two: pursue the claim on purpose, with specialists. If the diagnostic claim is genuinely the business, it becomes a funded regulatory program with a consultant, a quality system, and a clinical evidence plan — not a copy change.
The failure mode is the middle: a company that makes device-shaped claims in its marketing while operating as a consumer app. That position gets you the regulatory exposure without the regulatory asset, and it is also increasingly the thing app stores and advertising platforms police.
This is where we say the unprofitable thing. We have told prospective clients that the feature they most wanted to build was the one we would not build the claim for, and that the honest version of their product was smaller than the pitch deck. Some of those conversations ended the deal. We would rather have that conversation in week one than at a submission or a takedown.
What we do and do not do here
We build wellness, fitness, and telehealth products, and we map intended-use boundaries and claims inventories during planning — that is a specific deliverable in the Healthtech & Mental Health MVP Blueprint at $1,999 over seven days. We also build the technical controls that keep a product inside its intended-use boundary: constrained AI outputs, escalation paths, claim-safe copy review, and the regression testing that evidences it.
We do not determine whether your product is a regulated medical device. We are not a regulatory consultancy and we do not issue any form of clearance, approval, or certification. What we will do is raise the question early, tell you when we think you need a specialist, and refuse to write a claim we think crosses the line. That boundary is published on our trust page and we hold it in sales conversations.
This article is general, structural information about how US medical device regulation treats software. It is not legal or regulatory advice, and device status depends on facts specific to your product and claims. Engage qualified regulatory counsel before making a determination.
If you want a concrete next step: send us your app store description and your homepage, and tell us what the product actually does. That comparison is usually where the conversation starts. Get in touch, or see the pricing page for what a scoped build costs.
Frequently asked questions
Does my health app need FDA approval?
Most consumer wellness apps do not, because their intended use sits within the general wellness policy — maintaining or encouraging general health, at low risk, without disease claims. The determination turns on your claims rather than your technology, and it is a question for regulatory counsel, not for a builder or a blog post.
What makes a wellness app become a medical device?
A claim that the product diagnoses, screens for, treats, mitigates, or prevents a specific disease or condition, or that it affects the structure or function of the body. Adding "detects" or a named condition to marketing copy is the most common way this happens, and it usually happens after engineering has finished.
Can I say my app "monitors" a condition?
Be careful. Monitoring for a disease state is closer to a device claim than tracking a physiological metric. "Track your heart rate" and "monitor your heart for arrhythmia" are very different sentences legally. This is exactly the wording where a regulatory specialist earns their fee.
Does an AI chatbot in a wellness app make it a medical device?
Not by itself. The risk is that the model produces diagnostic or treatment output at runtime regardless of your intended framing. Constrain the output surface, test adversarially every release, keep the evidence, and build real escalation paths — those are product requirements, not prompt engineering.
We're outside the US. Does this apply?
This describes the US framework only. The EU operates under its own medical device regulation with a different classification structure that many software products find stricter, and the UK, Canada, and Australia each have their own regimes. If you are launching in multiple markets, treat them as separate regulatory questions with separate specialists.
Can Zee Palm tell us if our product is a device?
No, and any studio that says it can is overreaching. We map intended-use boundaries and claims during planning, we build the technical controls, and we tell you when the question needs a specialist. The determination itself belongs to qualified regulatory counsel.
What happens if we get this wrong?
Enforcement, product removal, and required corrective action are all possible, and app stores and ad platforms have their own removal processes that move faster than regulators do. The more common practical outcome is a stalled enterprise sale, because a hospital's compliance team will ask the question during procurement and an unclear answer ends the deal.