The most expensive time to learn that software may be a medical device is after the product, claims and architecture are already locked. Start with intended use, user, risk and regulatory lane before writing the roadmap.
The claim can change the regulatory problem
Two apps can use similar code and face very different regulatory questions because they are intended to do different things. Software that schedules appointments is not the same as software that analyzes a patient signal and recommends a clinical action. FDA's Digital Health Center of Excellence and device-software guidance emphasize the importance of software function and intended use. Before debating architecture, write the exact claim: who uses the product, what information it receives, what output it produces and what decision that output is intended to influence. Marketing language is not separate from regulatory strategy; it can define the promise you are making.
Separate wellness, administrative and medical functions
Some digital-health functions may fall outside FDA device oversight, while others may be device functions subject to requirements depending on intended use and risk. Clinical decision support is especially nuanced. FDA issued final guidance in January 2026 explaining certain CDS functions and the criteria relevant to whether a function is excluded from the device definition. Do not rely on a competitor's label or app-store category. Map every material feature to its user, input, output and clinical consequence, then identify which features drive the regulatory posture.
Regulatory architecture belongs in product architecture
If a function is regulated, design controls, software documentation, cybersecurity, validation and change management can affect how you build. A founder who discovers those obligations after launching may need to reconstruct design history and evidence. Keep requirements, risk analysis, verification and version history from the beginning when there is a credible device path. Separate regulated and non-regulated functions where feasible so one high-risk capability does not automatically entangle unrelated features. Qualified regulatory counsel or an experienced regulatory professional should review the specific product; this guide is a strategy map, not a classification decision.
AI makes change management more important, not less
Machine-learning systems can change through model updates, data changes, prompts, thresholds or workflow modifications. For medical-device software, ask what changes could affect safety or effectiveness and what evidence would be needed before deployment. Avoid selling investors a story in which the model 'learns continuously' without a controlled change process. Define model version, data provenance, performance metrics, subgroup analysis where relevant and rollback procedures. In health technology, reproducibility and traceability are part of product credibility.
Build the evidence plan with the buyer workflow
Regulatory clearance or authorization does not guarantee adoption. Health systems still care about workflow fit, security, integration, reimbursement, clinical evidence and who is accountable for the output. Map the clinical workflow from trigger to decision: where does your software enter, what action changes, who reviews the result and what happens when it is wrong? That map guides usability studies, integration decisions and the evidence package. Black founders can save capital by proving workflow value before building features that clinicians will not use.
The pre-build regulatory sprint
Week 1: write intended-use and claims statements in plain language. Week 2: inventory every feature and identify the functions with potential medical-device significance. Week 3: review FDA's device software, digital health and clinical decision support guidance against those functions. Week 4: build a regulatory question list for qualified counsel or a regulatory consultant. Week 5: align the product roadmap with evidence, quality and cybersecurity needs. Week 6: update the investor and customer story so the regulatory path is explicit rather than hidden. The objective is not to make the product less ambitious. It is to know which ambition carries regulated obligations before you finance it.
Create a claims-to-evidence table
Make a table with one row for every material product claim. Columns: exact claim, intended user, patient or subject population, input data, output, decision influenced, harm if wrong, evidence required, regulatory question, and current supporting data. If marketing wants to say 'detects deterioration earlier,' ask earlier than what, in which population, measured how, and what action follows. If the feature merely organizes clinician-authored information, write that accurately instead of allowing copy to drift toward diagnosis. Then connect every high-risk claim to the product requirement and verification plan. This table forces marketing, engineering, clinical and regulatory thinking into one artifact. It can also prevent fundraising language from getting ahead of the product. Investors may reward ambition, but regulators and health-system buyers will examine what the software actually does. For AI features, add model version, training or reference data, performance metric, subgroup checks, human-review role and known limitations. Revisit the table whenever the product changes. A new dashboard may be low impact; a new recommendation that changes clinical action may not be. The strategy is to make regulatory consequences visible at the feature-decision moment, when changes are still cheap, rather than after launch when claims are embedded in sales materials, contracts and user expectations.
Research behind this guide
Use the primary sources below to verify current rules, eligibility and program details before acting. Program terms can change.