---
title: Case Study: Pivoting from Wellness to Medical Device
description: Anonymized case study of pivoting from wellness to medical device: how a beachhead strategy and a disciplined intended purpose rewrite enabled CE marking. 
authors: Tibor Zechmeister, Felix Lenhard
category: MedTech Startup Strategy & PMF
primary_keyword: pivoting wellness medical device case study
canonical_url: https://zechmeister-solutions.com/en/blog/case-study-pivoting-wellness-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Case Study: Pivoting from Wellness to Medical Device

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A composite case: a wellness-app company with paying users and positive cash flow decided to pursue MDR qualification for a narrow clinical use case. They did it by keeping the wellness product alive, carving out a separate intended purpose, and treating the medical device as a disciplined beachhead rather than a rebrand. Eighteen months later, CE mark in hand. The original wellness business still funding the company.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Composite, anonymised teaching scenario. Not a specific named company.
- The founders did not "convert" the wellness product into a medical device. They created a distinct device with a narrower intended purpose under MDR Article 2(1) and 2(12).
- The wellness app continued to ship updates without regulatory constraints. The medical device was its own controlled artifact with its own QMS scope.
- Beachhead strategy: one clinical condition, one user group, one care pathway. Nothing broader.
- The intended purpose under Article 2(12) was written so it was true, specific, and defensible — not aspirational.
- Total cost from decision to CE mark was meaningfully lower than a cold-start because the company had real user data and engineering discipline from day one.

## Why this matters

Most wellness-to-medical-device pivots we see fail for one of two reasons. Either the founders try to reclassify the existing wellness product as a medical device (which forces every past marketing claim, every past user interaction, and every past promotional slide to be reconciled with MDR), or they try to keep doing everything at once and underestimate how much the medical device workstream will consume.

The composite case below got both of these right. It is worth studying because the moves it made are replicable by most wellness-first companies with the discipline to say no to scope.

This is an anonymised composite. Details are blended from multiple companies. No specific startup is identifiable.

## What MDR actually says

Two articles determine whether you are inside or outside MDR scope.

**Article 2(1)** defines a medical device. In substance: an instrument, software, or similar article intended by the manufacturer to be used for human beings for one or more specific medical purposes including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, and which does not achieve its principal intended action by pharmacological, immunological or metabolic means. The determining factor is the manufacturer's intended purpose, not the technology.

**Article 2(12)** defines intended purpose as *"intended purpose means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"*.

Read those two definitions together carefully. They mean your promotional material, your website, your app store description, and your sales statements all count toward establishing intended purpose. You cannot disclaim your way out of MDR scope if your marketing says the product diagnoses, treats, or monitors a disease. And you cannot accidentally pull a wellness product into MDR scope by writing one careless marketing line.

**Article 7** prohibits misleading claims. A wellness product that hints at medical benefits without MDR compliance is in violation. A medical device that over-claims beyond its certified intended purpose is also in violation.

**Article 51** assigns classification based on intended purpose and the Annex VIII rules. For software, Rule 11 typically governs. A narrow intended purpose often lands on a lower class than a broad one, which is the strategic lever behind beachhead thinking.

## A worked example

The composite company in this case:

**Starting point.** A wellness app with roughly 180,000 paying users, monthly subscription model, profitable. The app offered general wellness tracking, habit coaching, and lifestyle insights. None of the claims were medical. Legal had done their job.

**The trigger.** A clinical research group approached the founders with data suggesting the app's underlying data stream correlated meaningfully with a specific, well-defined clinical condition. The research group wanted to formalise the correlation into a clinical decision support tool for a specific care pathway.

**The wrong move they did not make.** The founders did not pivot the whole app into a medical device. They did not rewrite the wellness marketing. They did not try to re-qualify historical users. Every one of those moves would have dragged the entire commercial product into MDR scope.

**The right move.** They created a separate product: same underlying data science, different intended purpose, different user interface, different distribution channel, different clinical claims. The medical device was offered only to clinicians and only for the specific care pathway. The wellness app continued to exist untouched, serving the broader consumer audience with no medical claims.

**The beachhead.** One condition. One patient profile. One clinician user group. One care pathway. The founders resisted every temptation to broaden scope. When the notified body later asked whether the device could be used for adjacent conditions, the answer was no, and the Technical Documentation proved it.

**Intended purpose statement.** Drafted in plain language, specific about patient population, care setting, clinical question answered, and what the device does not do. Reviewed by clinicians for accuracy. Stress-tested against MDR Article 2(12). The discipline of writing a narrow intended purpose is the single highest-leverage act in this kind of pivot.

**Classification.** Under Annex VIII Rule 11, the device landed on Class IIa based on the specific intended purpose. Had the founders written a broader intended purpose covering disease diagnosis, Rule 11 would have pushed it to Class IIb or III. Narrow scope kept the class manageable.

**QMS and software lifecycle.** They stood up an EN ISO 13485:2016+A11:2021 QMS scoped only to the medical device. The wellness app stayed outside QMS scope. EN 62304:2006+A1:2015 applied to the medical device software lifecycle. The shared codebase was handled with a documented architectural separation and SOUP evaluation for the wellness components reused in the medical product.

**Clinical evaluation.** They had real-world usage data from the wellness product. None of it was usable directly as clinical evidence for the medical device because it was not collected under MDR-compliant conditions with a medical intended purpose. But they used it as state-of-the-art context and as justification for the clinical investigation design. The clinical investigation itself was small, targeted, and decisive.

**Timeline.** 18 months from decision to CE mark. Faster than a cold start because the engineering team was already disciplined, the data infrastructure was mature, and the company was profitable so there was no bridge-funding pressure.

**Outcome.** Medical device launched into a narrow clinical channel. Wellness app continued to fund the company. The two products never collided because the intended purposes, user groups, and marketing channels were kept distinct.

## The Subtract to Ship playbook

This is a textbook beachhead pivot. The moves to replicate:

**Treat the medical device as a new product, not a rebrand.** Separate intended purpose. Separate user group. Separate marketing. Separate QMS scope. Separate Technical Documentation. Shared codebase is fine if architecturally separated and documented.

**Write the narrowest intended purpose that is commercially meaningful.** Every word you add broadens the classification, the clinical evidence burden, the GSPR checklist, and the notified body review scope. Article 2(12) rewards precision.

**Keep the wellness product alive and untouched.** It funds the pivot. Do not let regulatory affairs rewrite the wellness marketing unless there is an actual Article 7 misleading-claims problem.

**Resist scope creep from the notified body and from internal stakeholders.** Every "could it also be used for..." question answered with yes becomes a new GSPR, a new hazard, a new clinical data requirement.

**Map shared code explicitly.** EN 62304 requires a software architecture description. If the medical device reuses components from the wellness app, document the interface, treat the reused components appropriately, and show the notified body the control boundary.

**Use wellness data as state-of-the-art context, not as clinical evidence.** Data not collected under Article 61 and Annex XIV conditions cannot substitute for clinical evaluation evidence. It can, however, justify design decisions and inform the clinical investigation plan.

**Plan the clinical investigation as small and decisive.** A narrow intended purpose means a narrow clinical question. Narrow clinical questions need smaller studies. This is where the beachhead pays off twice.

**Keep the medical device team small and separate.** A single QA/RA owner, a product lead, a clinical lead, and a few engineers with protected focus. Cross-contamination with the wellness product team dilutes both.

For a deeper treatment of beachhead strategy as a regulatory lever, see the dedicated post linked below.

## Reality Check

- Is your intended purpose statement narrow enough to survive a notified body scrutiny without scope creep?
- Have you separated the medical device QMS scope from the wellness product, or are you entangling both?
- Does any line in your current wellness marketing cross into medical claims under Article 2(1)?
- Can your wellness product continue to fund the company during the 12 to 24 months of MDR work?
- Are the medical device team and wellness team structurally separated, or sharing the same Jira and the same meetings?
- If the notified body asks whether the device can be used for an adjacent condition, can you show Technical Documentation that says no and explains why?
- Have you used wellness-product data as state-of-the-art context rather than as clinical evidence?
- Do you have a written rule about what triggers a re-classification review if the intended purpose evolves?

## Frequently Asked Questions

**Can we reuse code from our wellness app in the medical device?**
Yes, but it must be documented as software of unknown provenance or equivalent under EN 62304, with an architectural description and appropriate evaluation. A clean control boundary between medical and non-medical components is critical.

**Do we have to pull our wellness app off the market during MDR work?**
No. If the wellness app does not meet the Article 2(1) definition of a medical device and does not make medical claims, it is outside MDR scope regardless of what you are building alongside it. Do a line-by-line claims review before starting.

**Can we use our existing user data as clinical evidence?**
Usually no, because the data was not collected under MDR-compliant conditions for a medical intended purpose. It can be useful as state-of-the-art context and to inform clinical investigation design.

**How narrow should our intended purpose be?**
Narrow enough to be clinically true, specific about patient population and care setting, and defensible with evidence you can actually generate. Broader is not better. Article 2(12) rewards precision.

**Does a wellness-to-medical pivot always need a clinical investigation?**
Not always. Class I and some Class IIa devices can reach sufficient clinical evidence through literature and equivalence routes. It depends on the intended purpose, the classification, and whether equivalence is genuinely claimable under the three-pillar test.

**What is the biggest risk in this kind of pivot?**
Scope creep. Every time someone in a meeting says "and it could also do this," the regulatory burden grows. Discipline the scope or the scope will discipline your runway.

## Related reading
- [Beachhead strategy for MedTech startups](/blog/beachhead-strategy) — the strategic frame this case applies.
- [Wellness first, medical device later](/blog/wellness-first-medical-device-later) — the sequencing pattern behind this pivot.
- [Medical device vs wellness product](/blog/medical-device-vs-wellness-product) — where the boundary sits under Article 2(1).
- [Define intended purpose without over-constraining](/blog/define-intended-purpose-without-over-constraining) — the core craft of Article 2(12).
- [When to pivot a MedTech startup on regulatory grounds](/blog/when-to-pivot-medtech-regulatory) — decision framework for this kind of move.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 2(1), 2(12), 7, 51, 61, Annex VIII, Annex XIV Part A.
2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
3. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes.
4. MDCG 2019-11 Rev.1 (June 2025) — Guidance on qualification and classification of software in Regulation (EU) 2017/745.

---

*This post is part of the [MedTech Startup Strategy & PMF](https://zechmeister-solutions.com/en/blog/category/startup-strategy) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*