The transition from MVP to regulated medical device

Whether you’re adapting an existing MVP or building with regulatory requirements in mind from the start, three decisions will shape your development strategy, timeline, and budget. They include answering where teams get stuck, what the work costs, and how the FDA’s February 2026 QMSR and its guidance on PCCPs shape the strategy for AI-enabled SaMD.

The moment your MVP becomes a medical device

A lot of digital health MVPs start out as tools to help people stay well, ways for healthcare professionals to work together, apps to help them get things done, or ways to track symptoms. Then, a few releases in, a feature lands that crosses a regulatory line and changes the intended use.

Once a product makes or supports medical claims such as diagnosis, treatment, prevention, or certain clinical decisions, the team needs to determine if it falls within the medical-device framework, whether it’s a diagnostic algorithm or a telemedicine platform that starts advising on care. Not every decision-support feature triggers the framework, though: under the 21st Century Cures Act, some clinical decision support functions sit outside the device definition entirely, and FDA’s Clinical Decision Support Software final guidance, issued in January 2026, clarifies which functions qualify as “Non-Device CDS” — which is exactly why the determination has to be made, not assumed.

Under EU MDR’s Annex VIII Rule 11, as interpreted in MDCG 2019-11 Rev.1, software that provides information used for diagnostic or therapeutic decisions classifies as Class IIa at minimum. If a wrong output could cause serious harm — a missed diagnosis, a dangerous treatment choice — the same rule moves the product up to Class IIb or III, with heavier evidence demands at each level.

In the US, classification depends on the intended use, the risk it carries, and whether a suitable predicate device exists — though many SaMD products do land in Class II. From there, how long regulatory review may take depends on the assigned review pathway: in an analysis of ML-enabled devices FDA authorized in 2024, most cleared through 510(k) with a median FDA review of about five months, while De Novo reviews ran closer to a year.

Five months versus a year isn’t regulatory trivia — those extra months of review decide how long the program runs before it returns anything. The earlier classification gets locked, the cleaner the scoping work in MVP development becomes.

{{banner}}

Between an MVP and a cleared device

The transition from an MVP to a medical device requires a series of connected decisions that reshape the company’s workflow, documentation, and release process. It starts with defining the product’s intended use, which determines its regulatory classification, evidence needs, and scope.

With those boundaries set, the work shifts to quality: bringing processes up to the required standard, reconstructing records for what’s already built, and integrating design controls, risk management, and software lifecycle documentation into ongoing development. Few MVPs have much of this in place, so the effort required to address these shortcomings can determine the project timeline.

Finally, the team must establish the clinical evidence required for regulatory review and define how future changes will be assessed and documented. This helps subsequent versions reach the market without necessarily requiring a new regulatory filing for every release. Each decision builds on the previous one, so let’s take a look at them in the correct order and in more detail.

Step 1: define the intended use before moving forward

The intended use statement anchors the submission: everything else in it is judged against the claim it makes. It tells the reviewer in 3–5 sentences what the device is for, who uses it, and what clinical decisions it supports. Until it’s written down and approved, classification, risk analysis, and evidence planning are all guesses — and so is the number you give your board.

A good statement should clearly define: clinical function (identifying, predicting, monitoring, etc.), target patient population (age range, condition, exclusion criteria, etc.), use environment (a hospital, outpatient clinic, primary care setting, or home), intended user (a physician, nurse, technician, or patient). These details shape the device’s regulatory classification, evidence requirements, and human factors validation.

Take a hypothetical mood-tracking app — call it GlowMind. Here are two types of its positioning:

These two versions of GlowMind illustrate how different intended uses can lead to different regulatory obligations, evidence requirements, and commercialization strategies.

Why the intended use sets everything else

A wellness app that “helps users track their mood” is not a medical device. If you change the code so that it helps GPs to spot depression, it will likely be a Class II device in the US and Class IIa or higher under EU MDR. It’s the same product idea, but the two plans are completely different.

Companies that skip market research and early definition of the product’s purpose may end up with a compliant product that has little demand. Market and regulatory evidence need to inform each other. With the intended use clearly defined, classification becomes more manageable. It may still require regulatory research and predicate analysis, but teams have a clearer starting point for assessing applicable requirements.

If the intended use is unclear, you’re not just delaying regulatory decisions. You’re making product and investment decisions without knowing what evidence you’ll need.

Step 2: retrofit the quality system without burning the team

An MVP built to test a product idea rarely has all the processes and records needed for medical device compliance. On February 2, 2026, the FDA’s Quality Management System Regulation (QMSR) took effect, replacing the previous Quality System Regulation and incorporating ISO 13485:2016 by reference. For teams targeting the US market, this makes ISO 13485 central to the FDA’s quality system requirements. The standard has also long been used by medical device manufacturers in the EU, where it supports regulatory compliance.

For software-based medical devices, three frameworks address different but connected parts of this work:

• ISO 13485 establishes the quality management system, covering processes from design and development through post-market activities.
• ISO 14971 sets out a systematic approach to identifying hazards, evaluating risks, implementing controls, and monitoring risks throughout the device lifecycle.
• IEC 62304 defines software lifecycle processes, including development, maintenance, and problem resolution. It assigns software safety classes A, B, or C according to the potential harm a software failure could cause.

Together, these frameworks shape how a team develops the product, manages risks, and documents evidence that its processes and outputs meet the applicable requirements.

What a quality system retrofit involves

The challenge is that much of the MVP’s development work has already happened. The team needs to reconstruct the records necessary to explain and support that work, while introducing processes that generate the right documentation from the next sprint onward.

For the existing MVP, this typically involves rebuilding or consolidating:

1. User needs and design inputs: What the product must do, based on its intended use, clinical workflows, and user requirements.
2. Design outputs: What the team actually built, linked to the requirements the product must meet.
3. Verification and validation evidence: Whether the implementation matches its specified requirements, and whether the finished device meets user needs and its planned use.
4. Risk management records: Identified hazards, risk evaluations, implemented controls, and assessments of residual risk.
5. Software lifecycle records: Relevant architecture and design documentation, unit and integration testing, system testing, and problem resolution history.

MVPs often lack complete design inputs, verification and validation evidence, and risk management records. Reconstructing them takes time because the team must recover decisions, test results, and technical context from work that may not have been documented for regulatory purposes. That’s why a compliance specialist working alone usually cannot complete the retrofit: engineers who understand the product need to help establish what was built, why it was built that way, and what evidence supports it.

Structured healthcare software testing can support this process by identifying untested requirements, exposing defects, and generating evidence for verification and validation. Testing alone, however, cannot replace missing design records or establish that every regulatory requirement has been met.

Digital therapeutics example: myReha

myReha is a certified digital neurotherapy platform from Vienna-based nyra health, used by patients recovering from stroke, Alzheimer’s disease, and multiple sclerosis — mostly older adults working through exercises for months at home on tablets and smartphones. Unlike a general wellness app, myReha serves defined neurological rehabilitation needs, which makes clinical context central to its product design.

Halo Lab’s designers worked on both sides of the product. For patients, therapy plan navigation was built around streaks, milestones, and weekly goals — progress a user with neurological impairment can read at a glance. For clinicians, the clinic dashboard was redesigned around prioritized therapist actions: patient status, add, discharge, and restore are visible without a click-path, with search and filters on top. The team also designed the insurance-workflow screens that connect the platform to Germany’s statutory system. As documented in Halo Lab’s case study, myReha supports 50,000+ patients across 100+ clinics, with insurance-covered access for 35M+ Germans.

In a regulated product, important design decisions need a traceable rationale tied to user needs, requirements, and risk controls — and for teams building regulated medical software, documenting that rationale as they go creates clearer links between user needs, design requirements, and validation activities.

Get the right expertise in place before the retrofit starts

The retrofit requires regulatory, quality, and engineering expertise, whether provided by employees, contractors, or an external partner. A regulatory affairs lead clarifies submission requirements, a quality engineer establishes and maintains the required processes, and a senior engineer connects those requirements to the software architecture, development workflow, and testing practices.

When these responsibilities fall to an overstretched development team and an occasional consultant, decisions can stall, and documentation can fall behind. Bringing the right expertise in early helps the company address existing omissions without slowing ongoing development unnecessarily.

{{banner-2}}

Step 3: plan the evidence and the next ten releases

Before a medical device can reach the market, the team needs evidence that it performs as expected and is acceptably safe. But getting the initial version cleared is only part of the challenge. If the product will continue to evolve, there must be a plan for how future changes will be tested, documented, and reviewed by regulators.

Evidence requirements depend on the device’s intended use, risk, and regulatory pathway. A lower-risk device may rely primarily on non-clinical testing, while a higher-risk clinical decision-support tool may require clinical investigation.

The aim is to gather enough to support the claims the manufacturer is going to make. Broader clinical claims generally require stronger evidence, increasing the time and cost of development. A narrower claim set may allow a more focused submission, with more added later if additional evidence supports them.

The team should also identify which post-launch changes it expects to make. For AI-enabled devices, some planned modifications may be covered by an FDA Predetermined Change Control Plan (PCCP).

PCCP scope: what belongs in the plan

A PCCP must specify and justify the modifications it covers. The following examples illustrate potential candidates and changes that may fall outside its scope. Eligibility depends on the device, the proposed plan, and FDA review.

Potential candidates for a PCCP:

• Retraining a model on new data from the same modality and target population.
• Adjusting thresholds based on post-market performance.
• Adding input data sources without changing the product’s purpose.
• Updating algorithms within the boundaries defined in the authorized plan.

Changes that may require a separate submission:

• Expanding the intended use to a new patient population.
• Adding a new clinical claim, such as moving from screening to diagnosis.
• Introducing a fundamentally different model architecture.
• Adding a new indication or disease state.
• Changing the target user from a clinician to a patient.

These distinctions should inform the roadmap before version 1 is submitted. By identifying likely updates early, the company can plan the supporting evidence, validation work, and regulatory review for each release instead of addressing those requirements only when a change is ready to ship.

What the MVP to medical device transition actually costs

Money is the second-hardest conversation in a transition; only the timeline conversation is more complicated. Unlike the initial development budget, which depends on factors such as those covered in our guide to telemedicine MVP costs, the transition to a regulated medical device introduces additional expenses for quality systems, clinical evidence, and regulatory review. The figures below are planning estimates, not industry tariffs — actual budgets vary with product type, complexity, and regulatory requirements.

The intended-use and classification work is the cheapest part: typically a few weeks of senior consulting — budget in the low tens of thousands of dollars. The payoff: most of what you spend later follows from the decisions made here.

The majority of the money is spent on the quality system retrofit. For a Class II SaMD with a moderate MVP, plan for several months of work and a six-figure budget.

Clinical evidence is the variable: a clinical investigation can cost anywhere from the low six figures to over a million dollars, depending on design and sample size. Developing a PCCP requires planning and validation work, but an authorized plan can help reduce the need for separate submissions for covered modifications. You’ll also need to budget for the initial submission, notified body fees for CE marking, and the team responsible for maintaining compliance after launch.

Before you commit to the regulated path

The intended use defines the claim, the quality system documents how the claim was built, and the evidence plan shows the claim holds. Teams that respect the sequence get from a working MVP to a defensible submission and don’t pay for the same work twice.

Not every product should make the trip, though. If the same value can ship under a wellness or care-coordination intended use, scoping the clinical claim out is cheaper than scoping a QMS in. If you are going to make the trip, some questions are worth answering before you commit any budget. Can you write the intended use in three sentences today — and would your commercial team recognize the product in them? Who inside the company will own the regulatory position, rather than renting it from a consultancy? Which parts of the product do you expect to change in the next 18 months — and could those planned modifications form the basis of a PCCP that reduces the need for future submissions?

{{banner-3}}