You built a health app in a weekend. The EU might call it a medical device.

Shipping software has become remarkably easy. With AI coding tools, a working health app, a symptom checker, a dosage helper, a mole scanner, a sleep coach, is a weekend project. The tools will happily build it, the app stores will often list it, and nothing in your editor will mention that somewhere between "tracks your sleep" and "flags possible skin cancer" you crossed a legal line that exists whether or not you noticed it.

This is not a scare post. It is a map of where the line is, because the line is knowable, and being on the regulated side of it is survivable, plenty of tiny teams do it well. The genuinely risky position is not knowing which side you are on.

Where the line is

EU law does not care that you vibe-coded it, how many people work at your company, or whether it is free. It asks one question: what does your software claim to do? If the intended purpose is medical, diagnosis, prevention, monitoring, prediction, treatment or alleviation of disease, it is a medical device. A general wellness purpose, fitness, lifestyle, wellbeing, is explicitly not.

The words doing the work are intended purpose, and in practice that means your marketing. Your app store description, your landing page, your tweets. This produces outcomes that surprise developers:

"Track your sleep and feel more rested" is wellness. "Track your sleep to help manage your insomnia" is a medical claim about a condition. Same code, same data, different sentence, different legal category. "Log your moles over time" leans wellness. "Checks your moles for signs of melanoma" is a diagnostic claim, and under the EU's software classification rule that lands at Class IIa or above, meaning a notified body between you and the market. A chatbot that "answers questions about medication" versus one that "recommends your dose" is the same divide.

And for the AI builders specifically: if your model's output is used to make decisions about diagnosis or treatment, the classification rule puts you at Class IIa minimum, with higher classes when wrong output could cause serious harm. There is a further layer arriving on top: under the EU AI Act, AI-based medical devices at those classes are also high-risk AI systems. Two regimes, one product.

"But it's just an app" and other comforting thoughts

A few beliefs that do not survive contact with the regulation, listed gently. A disclaimer saying "not medical advice" does not undo a medical claim made everywhere else on the page; regulators read the whole picture. Being free does not exempt you; placing on the market includes free apps. Being small does not exempt you; the MDR has no headcount threshold. And "the app store approved it" is not a conformity assessment.

The inverse comfort is real, though: if your claims are genuinely wellness claims, you are genuinely not a medical device, and no amount of health-adjacent data changes that. The regulation polices claims, not vibes.

If you think you might have crossed the line

First, find out, properly and quickly. Our five-minute check answers the "am I a device at all?" question, and the classifier gives you the likely class and what it means, including which conclusions come straight from the rules and which are judgement calls worth confirming.

Then you have three honest options. Reword to wellness, if your actual ambition is a wellness product: tighten the claims, mean them, and carry on unregulated. Go regulated deliberately: for Class I software, self-declaration means a small disciplined team can do this without a fortune, a QMS, technical documentation, a signed declaration, and you are legally on the market, often in six to twelve months. Or pause the medical claims while you build toward them, ship the wellness version now, run the compliance work in parallel, release the medical claims when the paperwork exists to back them.

What you should not do is the fourth option, keep the claims and hope. Enforcement is patchy but real, competitors do report, and a takedown or forced retraction after you have users hurts far more than doing the work up front.

The part nobody tells vibe coders

The compliance work is more automatable than you think, and you of all people are equipped for that. The standards want requirements traced to tests, versioned releases, documented dependencies, a risk register, structured evidence, in other words, and generating structured artefacts from working practices is exactly what modern tooling is good at. That is the entire premise of QualiHQ: the discipline you already have, turned into the paperwork regulators need.

You shipped a product in a weekend. The regulated version is not a different universe, it is the same product with its claims made honest and its evidence written down. That is a bigger project than a weekend. It is much smaller than the folklore says.