There is no MDR-mandated eQMS platform and no notified body-approved vendor list. Under MDR Article 10(9) and EN ISO 13485:2016+A11:2021, the manufacturer has to run a risk-proportionate QMS and, under clause 4.1.6, validate whatever computer software supports it. That makes the eQMS selection a fit-for-purpose decision, not a brand decision. This post compares eQMS platforms for startups by category — US-style MedTech eQMS suites, EU-rooted MedTech platforms, and lightweight document-control tools — and gives a neutral build-vs-buy matrix and a selection playbook you can run in one week.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • The MDR does not name an eQMS vendor. MDR Article 10(9) requires a QMS proportionate to the risk class and type of device; the tool that supports it is a manufacturer choice.
  • EN ISO 13485:2016+A11:2021 clause 4.1.6 requires validation of the application of computer software used in the QMS before initial use and after changes, proportionate to risk. The tool you pick has to be validatable in your context.
  • eQMS platforms for startups fall into three broad categories: US-style MedTech eQMS suites, EU-rooted MedTech platforms, and lightweight document-control tools. Each category fits a different startup stage.
  • Build-vs-buy has a narrow window where build makes sense. For most funded early-stage MedTech teams, buying a focused tool and validating it lean beats building from scratch.
  • A neutral selection playbook gets a founder from longlist to signed contract in one week without getting trapped in vendor demos.

Why the eQMS question is loaded for startups

A founder who has just decided they need a QMS walks into a market with dozens of vendors, all of which claim to be MDR-ready, ISO 13485-compliant, and purpose-built for MedTech startups. Some of those claims are substantively true. Some are marketing. None of them settle the question that actually matters: does this specific tool fit the specific QMS this specific company is trying to run for the specific device it is building?

The framing Tibor uses in client work: the eQMS is a container. The QMS is the processes the company actually runs. A good container makes it easier to run the processes honestly. A bad container makes the team fight the tool instead of running the processes. And there is no container that, on its own, produces a QMS. The purchase of a tool is not the creation of a quality system.

This is why a neutral, category-level comparison beats a brand ranking. Brand rankings age fast, depend on the reviewer's incentive structure, and collapse the moment a vendor is acquired or pivots. A category comparison grounded in what the MDR and EN ISO 13485:2016+A11:2021 actually require ages well because the regulatory obligations do not move.

What an eQMS must support — the regulatory floor

Before comparing platforms, lock in the regulatory floor. Any tool you pick has to let you meet these obligations, not just display them on a marketing page.

MDR Article 10(9). The manufacturer of a medical device must establish, document, implement, maintain, keep up to date, and continually improve a quality management system that ensures compliance with the MDR in the most effective manner and in a manner that is proportionate to the risk class and the type of device. (Regulation (EU) 2017/745, Article 10, paragraph 9.) The tool has to support the processes Article 10(9) lists as minimum QMS components — strategy for regulatory compliance, risk management, clinical evaluation, product realisation, PMS, communication with competent authorities, management of non-conformities, and the rest of the enumerated elements.

EN ISO 13485:2016+A11:2021 clause 4.1.6. The organisation shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application. The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software. Records of such activities shall be maintained.

Clause 4.1.6 is the clause most founders miss when evaluating tools. It does not matter how polished the vendor looks — you, the manufacturer, must validate the tool for its intended use in your QMS, and you must be able to revalidate after vendor updates. A tool that pushes opaque updates, hides configuration changes behind "improvements," or cannot be pinned to a known-good state is hard to validate and will cost you audit time.

Clause 4.2.4 document control. Whatever tool you pick must enforce approval before issue, identify current revision status, ensure current versions are available at points of use, prevent unintended use of obsolete documents, and control external-origin documents.

Clause 7.4 purchasing. Your eQMS vendor is a supplier. The tool selection produces a supplier qualification record.

Everything beyond that floor — design controls modules, CAPA workflows, training matrices, supplier portals, PMS dashboards — is optional capability that helps or hurts depending on your device and your stage.

Must-have modules for an early-stage MedTech

A must-have module is one that maps directly to a clause of EN ISO 13485:2016+A11:2021 or a requirement of MDR Article 10(9) that your startup is actively running today. Everything else is optional.

For a pre-submission Class IIa or Class IIb startup, the must-have module set is usually: controlled document management (clause 4.2.4), training records (clause 6.2), CAPA and non-conformity (clauses 8.3 and 8.5), management review support (clause 5.6), internal audit tracking (clause 8.2.4), supplier management (clause 7.4), and risk management records tied to EN ISO 14971:2019+A11:2021. Design controls (clause 7.3) should be supported, though some startups run design controls in a dedicated engineering tool that integrates with the eQMS rather than inside the eQMS itself.

Modules you can often defer at seed stage: PMS dashboards, vigilance reporting workflows, advanced analytics, multi-site role hierarchies, and regulatory intelligence feeds. Turn them on when the process they support actually exists.

Categories of eQMS platforms on the market

There is no notified body-approved vendor list, and Tibor is independent of every vendor in this market. What follows is a neutral categorisation based on how tools are built and who they are built for — not a recommendation of any specific brand.

Category A — US-style MedTech eQMS suites

These are the broad, integrated platforms that grew out of the US medical device market and expanded into MDR coverage. They typically offer a deep module footprint — document control, training, CAPA, design controls, supplier management, complaint handling, audit management, risk management, PMS, and sometimes regulatory submissions — in a single integrated suite. Pricing is tiered and tends to be higher at entry-level than European alternatives. Validation packs are usually thorough and FDA Part 11 heritage is visible in the audit trail design.

Fit: later-stage startups, teams with US market ambitions, companies that want one suite for everything and can absorb the price and the validation effort.

Trade-off: the breadth can overwhelm a seed-stage team. You pay for modules you do not yet run, and clause 4.1.6 validation scope grows with every module you turn on.

Category B — EU-rooted MedTech platforms

These are the vendors built specifically around the MDR and EN ISO 13485:2016+A11:2021, often headquartered in the EU with EU data residency as a default. Module footprint is usually narrower and more opinionated — document control, training, CAPA, audits, management review, supplier management, and increasingly design controls and PMS. Configuration is often lighter and onboarding is faster. Pricing is frequently more startup-friendly.

Fit: EU-based MedTech startups whose first market is the EU, teams that prioritise MDR alignment over US regulatory parity, teams that want to be productive in weeks rather than months.

Trade-off: some of these platforms are young, change fast, and have smaller validation packs. You have to check clause 4.1.6 validation inputs carefully and plan for more vendor update revalidation effort.

Category C — lightweight document-control and workflow tools

These are general-purpose or lightly MedTech-adjacent tools — controlled document systems, lightweight workflow engines, audit trail layers on top of cloud drives, or specialised document control products that do one thing well. They do not pretend to be full QMS suites.

Fit: very early seed teams that need a clause 4.2.4-compliant document control layer plus a training attestation mechanism and not much else, and plan to migrate to a full eQMS later. Also a reasonable bridge for solo-founder pre-seed work.

Trade-off: you will outgrow the tool. Plan the migration from day one so the exit is cheap when you move.

All three categories can be compliant. None of them is inherently MDR-approved. The question is fit.

Build vs buy — the decision matrix

Build means assembling a QMS from general-purpose tools — a document repository, an electronic signature tool, a training tracker, a ticketing system — rather than buying an integrated eQMS. Buy means picking a tool from one of the three categories above.

Factor Lean toward build Lean toward buy
Team size Solo founder or two-person pre-seed Four or more people
Runway to first audit 18+ months Under 12 months
In-house QMS experience At least one person has run a QMS before No one on the team has built a QMS before
Device class Class I, non-sterile, non-measuring Class IIa, IIb, III
Budget for tooling Very tight, every euro counts against runway Tooling budget exists and is not the binding constraint
Appetite for validation effort Comfortable validating bespoke setups under clause 4.1.6 Want vendor validation inputs to lean on
Change tolerance Stable processes, few changes expected Rapid iteration expected before audit

The build path works, but it is a narrower window than the tooling market suggests. The most common failure mode is building a DIY QMS for cost reasons at seed, then having to migrate it into a bought eQMS six months before the notified body audit under time pressure. That migration costs more than the tool would have cost from the start.

The buy path works when the tool matches the stage. A Category A suite bought at pre-seed is usually wrong. A Category B platform bought at pre-seed is often right. A Category C tool bought at pre-seed is defensible if the founder has a clear migration plan.

Selection playbook — from longlist to signed contract in one week

This is the playbook we run with clients who need to pick an eQMS without spending a month in vendor demos.

Day 1 — scope your QMS. Write down, in one page, the clauses of EN ISO 13485:2016+A11:2021 you are actively running today and the ones you will activate in the next six months. Write down the MDR Article 10(9) QMS components your device needs. This is the requirements input to everything that follows. Without it, every vendor demo looks equally good.

Day 2 — longlist three to five vendors. One from each category if your situation is ambiguous. Two from the category that fits your stage if it is clear. Exclude vendors that cannot answer a direct question about EU data residency, clause 4.1.6 validation inputs, or their own supplier qualification documentation.

Day 3 — structured vendor demos. Send every vendor the same scripted scenario drawn from your actual processes — a document you need to control, a training record you need to issue, a CAPA you need to run, an audit trail query you need to answer. Watch each vendor execute the scenario in the tool, not in slides. A vendor that pushes back on running the scenario live is a red flag.

Day 4 — validation inputs and supplier qualification. Ask each shortlisted vendor for their validation pack, their change management policy, their ISO 27001 or equivalent security evidence, their data processing agreement, and their exit export mechanism. File the answers in your supplier qualification record under clause 7.4 — regardless of which vendor you pick, this file needs to exist.

Day 5 — price, contract, exit clause. Compare price per user at current team size and at expected team size in 18 months. Read the contract, especially data ownership, exit clause, and change notification terms. Negotiate the exit clause explicitly if it is weak.

Day 6 — shortlist to one. Pick the tool that best fits your actual QMS scope with the fewest turned-on modules you do not yet need. Smaller fit is better than bigger fit at this stage.

Day 7 — sign, provision, and start the clause 4.1.6 validation plan. Do not wait until right before the audit to write the validation plan. Write it while the tool is fresh in your head.

Common mistakes

  • Picking a Category A suite at pre-seed because the brand is recognisable, then paying for modules you do not run and validating functions you do not use.
  • Letting a vendor sales cycle drive the QMS scope instead of letting the QMS scope drive the vendor comparison.
  • Accepting "we are ISO 13485 validated" as a substitute for your own clause 4.1.6 validation of the tool's application in your QMS.
  • Running five vendor demos with unscripted walkthroughs, then choosing based on who was most charismatic.
  • Ignoring the exit clause in the contract because the sales cycle feels short and friendly.
  • Building a DIY QMS at seed to save money, then migrating under time pressure six months before the audit.
  • Selecting an eQMS before the procedures exist and letting the tool's default templates become the QMS.

The Subtract to Ship angle

The subtraction in eQMS selection is at two layers. First, at the vendor level — pick the smallest tool that meets your current scope, not the biggest tool that meets your imagined future scope. Second, at the module level — turn on only the modules that correspond to clauses you are actually running. Every active module is a module you validate under clause 4.1.6, train on, and maintain. Modules you turn on for optics cost real time and create audit surface area.

A well-picked eQMS, run small on purpose, frees the team to focus where judgement matters: writing procedures that describe real work, running processes honestly, producing records that match reality. A badly-picked eQMS creates a second layer of bureaucracy on top of the first and never recovers. The framework traces back to MDR Article 10(9)'s "proportionate to the risk class and type of device" — proportionate means proportionate in tooling too.

Reality Check — Where do you stand?

  1. Have you written down the clauses of EN ISO 13485:2016+A11:2021 and the MDR Article 10(9) QMS components your company is actively running today, before looking at any vendor?
  2. Can you describe, in one sentence, which category of eQMS fits your stage and why?
  3. Do you know the difference between the vendor's validation package and your clause 4.1.6 validation of the tool's application in your specific QMS?
  4. Have you run a scripted vendor demo based on your actual processes, or only watched slide-driven sales demos?
  5. Do you have a supplier qualification record for the tool you are about to pick, stored under clause 7.4?
  6. Is there a written exit clause in the contract that lets you walk away with your records in a reusable format?
  7. For every module you plan to turn on in the first 90 days, can you name the specific clause or MDR obligation it supports?

Frequently Asked Questions

Is any eQMS platform officially MDR-approved or notified body-approved? No. The MDR does not approve or certify eQMS vendors, and notified bodies do not publish approved vendor lists. Under MDR Article 10(9), the manufacturer is responsible for the QMS, and under EN ISO 13485:2016+A11:2021 clause 4.1.6, the manufacturer is responsible for validating the tool's application. Any vendor claiming to be notified body-approved is making a marketing claim, not a regulatory one.

What is the minimum eQMS footprint for a seed-stage MedTech startup? At seed stage, the minimum footprint is controlled document management, training records, CAPA and non-conformity tracking, internal audit support, management review support, and supplier management. Design controls and risk management records are usually run here or in linked tools. PMS and vigilance workflows can be deferred until the processes they support are running.

Can I use a general-purpose document tool as my QMS at pre-seed? Yes, if the tool lets you meet clause 4.2.4 document control requirements (approval before issue, version control, availability at point of use, obsolete prevention) and you can attach a training attestation and audit trail layer. You will outgrow it. Plan the migration from day one and keep the document structure portable so the move is cheap.

How long does clause 4.1.6 validation of an eQMS take for a small team? For a focused validation covering document control, training, CAPA, and audit trail, a small team can complete initial validation in one to two weeks of focused effort, proportionate to risk under clause 4.1.6. The ongoing revalidation effort depends on how aggressively the vendor pushes updates and how well you scope the revalidation to the functions actually affected.

Build vs buy — when does building a DIY QMS actually make sense? Building makes sense in a narrow window: solo founder or two-person team, long runway to first audit, at least one person with prior QMS experience, stable low-change processes, very tight budget, and a device class where the QMS footprint is small. Outside that window, buying a focused tool that fits the stage is usually cheaper once the full cost of later migration is counted.

Does the MDR say anything about which software I can use for my QMS? No. The MDR is silent on specific software tools. MDR Article 10(9) requires a proportionate QMS and does not specify how it is implemented. The software question is governed by EN ISO 13485:2016+A11:2021 clause 4.1.6, which places the validation obligation on the manufacturer for whatever tool is chosen.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10, paragraph 9 (quality management system requirement, proportionate to risk class and type of device). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 4.1.6 (validation of the application of computer software used in the quality management system), clause 4.2.4 (control of documents), clause 7.4 (purchasing).
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Referenced for risk management records typically held in or linked from an eQMS.

This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Zechmeister Strategic Solutions is independent of every eQMS vendor on the market. If you want a neutral second opinion on an eQMS shortlist before you sign, that kind of review is exactly the work we do with founders.