Same AI model, different product:where wellness ends and MedTech begins.

If a product misreads a sleep phase, that's an inconvenience. If it misses a risk of sleep apnea or arrhythmia, someone might not see a doctor. So in the second case the model is judged very differently. “Average accuracy” stops mattering much.

What matters is how many cases the model misses, how many false alarms it raises, and how it performs across different patient groups. You need data with clinically confirmed labels, clear provenance and proper patient consent, plus an independent test set the model has never seen.

Data collected in a wellness app is usually not fit for this. We run into this regularly, when clients come to us with a large dataset expecting to build on it.

The development process changes too. Risk management, a formal software lifecycle and a quality management system come in, and every requirement has to be traceable to code and to tests.

For AI teams the most painful discovery is usually that you can no longer retrain the model whenever you like. Every significant change has to be validated, and in the US there's a dedicated mechanism for this: a predetermined change control plan agreed with the FDA in advance. Even the interface becomes part of safety. It matters how the result is shown and what the person does next.

A claim isn't only what's written in the regulatory submission. It's your website, your App Store description, your ads, even the results screen. Regulators look at all of it together.

A few telling examples:

And in what order:

1. 01

   Start with research, not with the product.

   This is not the place to cut corners. Look at the regulatory landscape in every region you might eventually enter, because the rules differ a lot. The US has the FDA and its own wellness boundary. Europe has the MDR, which classifies software more strictly. Germany has its own DiGA system with reimbursement from statutory insurers.

   Look at which comparable products have already been cleared and with what intended-use wording — in the US, FDA databases make this public. Talk to potential buyers, clinics and insurers, about what they would pay for and what evidence they'd need. And get advice from a regulatory specialist. A couple of consultations early on cost a fraction of fixing a mistake later.

2. 02

   Then choose a direction.

   You don't need a detailed multi-year plan — nobody plans that way today, and that's fine. But you do need to answer honestly: do we want to keep the option of becoming a medical product? That should be a conscious decision, not an accident.

3. 03

   Be careful with wording from day one.

   Marketing shouldn't promise medicine before the company is ready to prove it. Otherwise, as the examples above show, someone else will decide what your claim is.

4. 04

   Collect data with the future in mind.

   That means consent that allows research use, clear data provenance, and versioning of datasets and models. It costs almost nothing if you build it in early and is almost impossible to reconstruct later.

5. 05

   Separate the future medical part in the architecture.

   If medical logic is spread across the whole app, the whole product ends up regulated. If it lives in a dedicated module, only that module is. At our company we always design for this when we see even a hypothetical medical trajectory for a client.

6. 06

   Build lightweight documentation habits.

   Not a full quality system from day one, just basic engineering hygiene: requirements, decisions, risks and tests are recorded and linked to each other. Teams that already work this way find the transition much easier, and not only technically.

In more detail, here's what usually has to be rebuilt if you didn't plan for the medical pathway from the start:

• Data without the right consent or without clinical labeling.
• Architecture you can't carve the regulated part out of.
• Security and compliance: HIPAA, GDPR, audits, data processing agreements — a clinic or insurer will ask about these before they ask about your AI. Trust around data is under growing scrutiny: in July 2026 the FTC sued telehealth company Hims & Hers, alleging it shared users' health information with advertising platforms despite promising privacy.
• Integrations: physicians won't work in a separate app, so the product has to fit into their systems and their workflow.
• Evidence: engagement metrics have to be replaced with studies of outcomes and economic impact.

I want to single out the business model, because in our experience it's one of the most problematic parts. HealthTech products are often built by people with a scientific or medical background. They know their field brilliantly, but have less experience with long B2B sales cycles, negotiating with payers and building a reimbursement model.

The market has plenty of examples of companies that got through the regulatory process and still didn't survive.

Data, studies, product architecture and processes are difficult to rank because in practice they can't be separated. The data shapes the study design, the study depends on the architecture, and the documentation describes the processes. If one link is weak, you end up rebuilding the whole chain.

If I had to prioritize, this is how I'd rank them:

• The most expensive in money and time is clinical studies. Recruiting patients, working with clinical sites, ethics committees. It takes months, sometimes years, and you can't speed it up with more engineers.
• The most underestimated is retrofitting. When a product was built without formal processes, you have to reconstruct traceability, re-validate modules and rebuild documentation. More than once we've seen with clients that rewriting the regulated part from scratch was cheaper than “documenting what's already there.”
• The most strategically dangerous is choosing the wrong intended use. A claim that's too broad means a higher risk class, expensive studies and a long pathway. One that's too narrow doesn't sell. This mistake costs more than any other, because everything else gets built around it: the study design, the architecture, the documentation.

And it's important to remember that regulatory clearance isn't the finish line. After it comes post-market monitoring, incident handling and re-validation with every significant model update. That's an ongoing operational load, and it has to be part of the company's model just like the market launch itself.