If you’re building a medical device startup in Europe, the EU Medical Device Regulation (EU MDR) can feel like a wall of acronyms, documents, and “we’ll deal with it later.” The fastest way to lose time (and money) is to postpone MDR until you’re “closer to market.” The fastest way to gain speed is to turn MDR into a simple sequence of decisions.
This EU MDR for Startups Guide gives you a startup-friendly roadmap: what to decide first, what to document early, and how to avoid the most common detours.
Quick context: what EU MDR actually expects
EU MDR is not “a checklist at the end.” It’s a lifecycle system that connects:
- Your intended purpose and claims
- Your risk classification
- Your evidence (clinical + performance)
- Your quality management system (QMS)
- Your technical documentation (Tech Doc)
- Your post-market surveillance (PMS) plan
For startups, the key is to build these in parallel—lightweight at first, then progressively more complete.
Step 1: Define intended purpose and claims (before you build too much)
Everything starts with words.
Write a one-page “intended purpose” draft:
- Target patient/user
- Medical condition or use case
- Who uses it (HCP vs. lay user)
- Where it’s used (home, clinic, OR)
- What it does (diagnosis, monitoring, treatment, decision support)
- What it does not do (boundaries)
Why this matters: intended purpose drives classification, clinical strategy, labeling, and your entire Tech Doc structure.
Startup tip: Keep claims realistic. Over-claiming early is the most expensive way to increase your regulatory burden.
Step 2: Confirm your device classification (and route to conformity assessment)
Once intended purpose is drafted, classify under MDR rules (Annex VIII). This determines whether you can self-certify (rare) or need a Notified Body (common).
Typical startup reality:
- Many software products become Class IIa or higher depending on impact on patient care
- If you need a Notified Body, plan lead times early (often months to a year)
Deliverable to create now:
- A short classification rationale (rule(s) applied + justification)
Step 3: Map your regulatory pathway like a product roadmap
Treat MDR like a roadmap with milestones:
- Classification confirmed
- QMS scope defined
- Technical documentation structure set up
- Clinical evaluation approach agreed
- Risk management established
- Verification/validation plan locked
- Notified Body engagement (if applicable)
- Submission package readiness
This prevents the classic startup trap: building features without knowing which evidence you’ll need to support the claims.
Step 4: Start your QMS early (but keep it startup-sized)
A QMS isn’t bureaucracy—it’s how you prove you build safely and consistently.
For most startups, start with the minimum set of processes that unblock development:
- Document control
- Design and development controls
- Risk management integration
- Supplier management (especially for software, cloud, outsourced dev)
- CAPA (corrective and preventive actions)
- Complaint handling
- PMS planning
If you plan ISO 13485 certification, align your QMS with it from day one. Retrofitting later is painful.
Step 5: Build risk management into daily work (not a one-time file)
Under MDR, risk management is continuous. Start with:
- Hazard identification (including cybersecurity and usability)
- Risk estimation and control measures
- Benefit-risk rationale
- Traceability to requirements and tests
Core deliverable:
- Risk management file aligned with ISO 14971
Startup tip: If your risk file doesn’t connect to your product requirements and test plan, it won’t survive review.
Step 6: Plan your clinical evaluation strategy early
Clinical evaluation is where many startups get stuck—especially software and AI.
Decide early:
- Can you leverage literature and existing clinical data?
- Do you need a clinical investigation?
- What is your “state of the art” and comparator?
- What evidence supports each claim?
Core deliverables:
- Clinical Evaluation Plan (CEP)
- Clinical Evaluation Report (CER) outline (start early, fill progressively)
Step 7: Set up your Technical Documentation structure (so you don’t rebuild it later)
Your Tech Doc is not one document—it’s a system of linked documents.
Create a folder structure that mirrors MDR Annex II and III:
- Device description and specification
- GSPR checklist (General Safety and Performance Requirements)
- Risk management
- Verification and validation (including software lifecycle, usability, cybersecurity)
- Clinical evaluation
- PMS plan and PMCF (if applicable)
Deliverable to create now:
- A Tech Doc index (table of contents + where each document lives)
Step 8: Don’t ignore post-market requirements (even pre-market)
MDR expects you to plan how you will monitor performance and safety after launch.
Start with:
- PMS plan
- Vigilance process
- PMCF plan (if required)
This also helps investors: a strong PMS story signals maturity.
Common startup mistakes (and how to avoid them)
- Waiting for “design freeze” before starting MDR: Start with intended purpose, classification, and QMS scope immediately.
- Over-claiming: Claims drive evidence burden.
- Treating the Tech Doc as a final deliverable: Build it progressively.
- No Notified Body strategy: If you need one, engage early.
- Risk management not linked to development: Make it part of requirements and testing.
A simple “start here” checklist (first 10 working days)
- Draft intended purpose + claims (1 page)
- Create classification rationale (Annex VIII)
- Decide if Notified Body is needed; outline timeline
- Set up Tech Doc structure (Annex II/III)
- Start QMS basics: document control + design controls
- Start risk management file (ISO 14971 aligned)
- Draft clinical evaluation plan outline
- Create a GSPR checklist skeleton
- Define your V&V strategy (what you must prove)
- Assign internal owners and weekly cadence
Final thought: MDR is a speed tool when you use it early
For startups, MDR done late feels like a blocker. MDR done early becomes a decision framework that prevents rework, de-risks fundraising, and accelerates market access.
If you want a quick, practical starting plan tailored to your product, book a free 60-minute MDR Strategy Calland we’ll map your next steps.
FAQ: EU MDR for startups
How early should a startup start MDR work?
As soon as you can describe your intended purpose and claims. That’s typically within the first weeks of product definition.
Do all startups need a Notified Body?
No, but many do—especially Class IIa and above. Your classification determines the conformity assessment route.
Is ISO 13485 mandatory under MDR?
MDR requires a QMS, and ISO 13485 is the most common way to demonstrate it. Many Notified Bodies expect alignment.
What’s the single most important MDR document to start with?
Your intended purpose and claims. Everything else flows from that.
Want a fast, founder-friendly MDR starting point?
If you’d like to sanity-check your classification, claims, and first deliverables before you invest months of build time, book a free 60-minute MDR Strategy Call.
https://calendly.com/niko-mangold-consultants/30min
In that call, we’ll typically:
- Clarify your intended purpose and claims (what you can say nowlater)
- Pressure-test likely classification and conformity assessment route
- Identify the first 5–10 documents that will unblock progress
- Map a realistic timeline (including Notified Body considerations if relevant)
Call outcome: you leave with a clear “start here” plan for the next 2–4 weeks.