Do I need an eQMS to get ISO 13485 certified?

No. ISO 13485 is a standard for your quality management system (the processes and documentation), not a requirement for specific software. Many companies achieve and maintain certification using a combination of document management tools, spreadsheets and controlled records. An eQMS makes compliance easier to sustain and audit-readiness easier to demonstrate, but the software is not the certification. The system is.

When is a spreadsheet not good enough?

When you can no longer reliably answer, "Who approved this document, which version was it, and when did that approval happen?" If you are in front of an auditor and cannot answer that in under two minutes, you have outgrown your spreadsheet. Also, if you are managing change orders for a device already in regulated distribution, you need controlled records.

How long does it take to implement an eQMS?

Most vendors quote four to twelve weeks, and that estimate almost always assumes you already know what processes you are implementing. If you are building your quality system at the same time as configuring the software, double the estimate and get a regulatory expert involved before you start, not after.

What is the most common mistake when setting up a QMS?

Building the documentation before building the processes. A QMS full of SOPs no one follows is worse than no QMS, because it creates the appearance of compliance while the real work happens outside the system. The process comes first. The documentation captures the process. The software stores the documentation.

How much does an eQMS cost for a startup?

Costs vary across platforms. Most charge a combination of an implementation fee and an annual subscription, priced by tier or seat count. Budget somewhere from a few thousand to tens of thousands of dollars a year depending on platform and team size, not including implementation services. Talking to a regulatory expert before you commit helps you avoid paying for capabilities you don't need yet.

What is the difference between an eQMS and a generic document management system?

A generic DMS stores and controls documents. An eQMS purpose-built for medical devices does that plus enforces device-specific workflows (design controls, CAPA, audit management, supplier qualification), provides regulatory-specific templates, generates audit-ready reports in the formats regulators expect, and often includes training management. Regulators want to see a system organized the way 21 CFR Part 820 and ISO 13485 expect, not the way a generic DMS happens to store files.

eQMS for Medical Device Startups: How to Choose

Q: What is the difference between ISO 13485 and the FDA QMSR?

ISO 13485 is the international quality management standard for medical devices, published by ISO. The FDA's QMSR (21 CFR Part 820, effective 2 February 2026) incorporates ISO 13485:2016 by reference, replacing the legacy Quality System Regulation. In practice, meeting ISO 13485 now closely aligns with FDA requirements, which simplifies dual-market compliance, with a small set of FDA-specific provisions retained.

The question every founder asks first, and why it's backwards

I talk to a lot of early-stage medtech founders, and when the conversation turns to quality systems the same question comes up in roughly the same order, "Which eQMS should we use?"

My answer usually surprises them. That is the last question you should be asking.

The software decision takes an afternoon. I can walk you through Greenlight Guru, Qualio and Formwork in a single call, tell you where each one earns its cost, and have a recommendation on the table before lunch. What I can’t hand you in an afternoon is a functional quality system. The documented processes, the trained people, the design-control discipline, the institutional knowledge of what your regulators actually want to see. That takes months, and it takes someone who has done it before.

Founders over-index on picking the tool because the tool is a concrete, purchasable thing. It arrives with a UI and a vendor success team. It feels like progress. But I have seen companies buy an eQMS in month two, log in faithfully every week, and arrive at their FDA submission with a beautiful, well-organized collection of incomplete and inconsistent documents. The software captured the work. It didn't do the regulatory thinking.

That distinction, software that captures versus a system that works, is what this piece is about.

An eQMS is a filing cabinet, not a quality system

An electronic quality management system is software that organizes and enforces your QMS documentation. It gives you a digital home for standard operating procedures, design history files, CAPA records, supplier qualifications, training logs and audit trails. It automates version control so you can prove which revision was in effect on a given date. It routes documents for approval, tracks signatures, and generates reports that look good in an audit.

What it is not: a quality system. That is a critical distinction.

The quality system is the set of processes your company has to run. How you control design changes, how you investigate nonconformances, how you monitor post-market performance, how you manage risk. ISO 13485 and the FDA's Quality Management System Regulation (which incorporated ISO 13485 into 21 CFR Part 820 effective 2 February 2026) define what that system must contain. The eQMS is just where you keep the paperwork.

Here is the way I describe it to founders. The eQMS is the cabinet. The quality system is what goes in the cabinet, and the discipline to fill it correctly. An empty cabinet organized by a beautiful app is still an empty cabinet.

What ISO 13485 and the FDA actually want to see

ISO 13485 is an international standard for quality management systems in the medical device industry. The FDA's QMSR (codified in 21 CFR Part 820) now incorporates ISO 13485:2016 by reference, replacing the legacy Quality System Regulation that had been in place since 1996. If you are selling into both the US and EU markets (which most of our clients are), a single ISO 13485-based QMS now covers most of both, with a small set of FDA-specific provisions retained.

The standard requires you to establish, document, implement and maintain a QMS. That language matters. "Establish" means you have to design the system. "Document" means write it down. "Implement" means actually run the processes, not just have them on paper. "Maintain" means keep it current as your products, processes and regulations change.

Concretely, a conforming QMS for an early-stage device company needs:

A quality manual or equivalent top-level document describing the scope and structure of your system
Documented procedures for design controls, risk management (ISO 14971), document control, records control, CAPA and supplier qualification
Evidence of training: people have to understand and follow the procedures, and you have to prove it
A management review process: senior leadership has to formally review QMS performance at defined intervals
Internal audit procedures
Post-market surveillance and complaint handling

None of that is a software feature. All of it is a process your team has to build and run. An eQMS makes it easier to do those things consistently and to demonstrate compliance in an audit. It does not replace any of them.

When you really need eQMS software, and when you don't

The honest answer depends on where you are in your journey.

Before you have any regulatory submission on the horizon. You probably do not need enterprise eQMS software yet. You need to understand your regulatory pathway, your device class and your submission strategy. That strategic layer comes first. A shared folder with disciplined version control can do the document job while you figure out the strategy. The goal at this stage is not to capture work. It is to do the right work.

When you are 12 to 18 months from a submission. This is when a proper quality system starts earning its cost. You have design outputs that need to be formally controlled, suppliers that need to be qualified, risk management activities underway. At this stage an eQMS is a real operational tool, not an aspirational one.

Before a notified body engagement or an FDA pre-submission. If a notified body is about to review your technical documentation, your QMS will be part of what they look at. It needs to be real, not just set up but operational. A notified body auditor who finds a clean Greenlight Guru environment with six months of empty records is not impressed.

What do you do before you are ready for software? Document the critical processes in plain text, establish a version-controlled folder structure, and get a regulatory expert involved early enough to shape the process design, not just the software implementation. The system design comes before the software selection.

The spreadsheet phase, and the moment it betrays you

Almost every early-stage founder goes through a spreadsheet phase, and there is nothing wrong with that, within limits.

A well-maintained spreadsheet tracker for design-history-file deliverables, a shared Google Drive with disciplined naming conventions, and a simple approval workflow in email can handle a pre-submission quality system at the right stage. I have seen it work. I have also seen it fall apart at exactly the wrong moment: during an audit, when a notified body asks to see your documented procedure for controlling design changes and you realize the procedure lives in someone's head, not on paper.

The transition to a formal eQMS makes sense when:

More than two or three people touch regulatory documents regularly
You are managing suppliers who need formal qualifications on file
You are operating under multiple SOPs that need controlled revision histories
A submission is six to twelve months out and you need an audit trail that will hold up

The risk of buying too early is that you pay for a platform before you have the processes to fill it. The risk of buying too late is that you scramble to migrate disorganized records into a new system under deadline pressure.

Five questions that settle the software choice

The eQMS market for medical devices is not small:

Greenlight Guru, a deep, medtech-specific platform with a strong content program, built specifically for device companies.
Qualio, a broader life-sciences platform (medtech, pharma, biotech) that publishes at industrial scale.
OpenRegulatory (Formwork), a transparent, low-cost monthly model aimed at lean, founder-led teams.
Ketryx, more enterprise-focused, particularly strong on software-as-a-medical-device and IEC 62304 workflows.
Certhub, a newer AI-native entrant focused on automating MDR/IVDR technical documentation.
Dovetail QMS Plus, pairs the platform with embedded regulatory experts, for teams who want the tool and the judgment together.

When I work with founders on this choice, here are the questions I tell them to answer first:

What device class and regulatory pathway are you targeting? A Class I FDA-exempt device has different documentation requirements than a Class IIa EU MDR device. The eQMS should handle your actual workflow, not a generic one.
What markets are you selling into first? US-only, EU-only and dual-market companies have meaningfully different document requirements and audit protocols.
How many people will actually use the system? Most eQMS platforms price by seat or by tier. A nine-person team has different economics than a fifty-person one.
Do you have in-house regulatory affairs expertise, or are you relying on a partner? This has more weight than founders expect. A steep-learning-curve platform is fine if your regulatory lead has ten years configuring QMS tools. It is not fine if that lead is you, running it for the first time while also leading product.
What does your validation burden look like? Regulated industries often require validation of the eQMS software itself (IQ/OQ/PQ). Some platforms provide pre-validated environments. Know what you are signing up for.

The honest summary. For most pre-Series-A medical device startups, the software decision is less consequential than founders think. The meaningful differences between the major platforms are real but second-order. The first-order decision is whether you have the expertise, in-house or partnered, to actually build and run the quality system that goes inside the software.

Design controls, in plain English

Design controls are the documented procedures that govern how you develop your device from concept to finished product. FDA 21 CFR Part 820.30 has required them since 1996, and the QMSR maintains the requirement. ISO 13485 Section 7.3 is the international equivalent.

The core of design controls is a design history file, the compilation of records that describes the history of a finished device's design. It includes:

Design inputs (what the device has to do, for whom, and the regulatory requirements)
Design outputs (the drawings, specifications and procedures that define the finished device)
Design reviews (formal, documented reviews at defined stages)
Design verification (confirming outputs meet inputs)
Design validation (confirming the finished device meets user needs and intended uses)
Design transfer (translating the design into production specifications)
Design changes (a documented procedure for changing the design without losing control of it)

The reason design controls matter in the eQMS conversation: a good eQMS has purpose-built modules for this workflow. A generic document management system does not. If your device is anything beyond the simplest Class I, this capability is not optional.

When your first quality system runs out of road

The advice above is calibrated for early-stage companies: pre-revenue, pre-submission, or within 12 to 18 months of a first filing. That is where most of the software-before-strategy mistakes happen.

The picture changes once your device is on the market and your team is growing. A Series A company running a Class IIb device, expanding to multiple sites, or migrating off a paper-based or legacy eQMS faces a different set of decisions: how to move compliance history to a new system without losing your audit trail, how to run one quality system across product lines, and how to structure your QMS to survive a 510(k) or CE-mark submission audit. Those questions are covered in the scaling and migration content in this cluster, which leads into a comparison of purpose-built tools (including how Dovetail QMS Plus sits against Greenlight Guru and Qualio for a buyer who is switching rather than starting from scratch).

Why we built Dovetail to work differently

I started Dovetail because I kept watching the same pattern. A founder buys the right software, configures it carefully, spends months populating it, and then gets a deficiency letter that reveals the system was built on the wrong regulatory strategy, wrong pathway, wrong classification, wrong submission type, wrong risk posture. The software was not the problem. The absence of an expert who could have caught those decisions in month one was.

Dovetail pairs an AI-native, verified eQMS with embedded regulatory leadership. Through Envoy, you get a senior regulatory expert (someone who has been in the room, handled deficiency letters, and knows what a notified body auditor looks for) working inside your team from day one. Dovetail QMS Plus is the platform, and its AI-native collaboration suite puts our agent right inside your documents, so it reads every comment and redline, drafts and reviews, flags inconsistencies, and keeps version history and compliance gaps in check. With Coworker, that same regulatory intelligence works inside your team's Slack. The expert leads and makes the strategic calls; the AI does the heavy lifting.

We are not a pure software vendor. We are a regulatory partner. The eQMS is part of what we bring. The regulatory expertise is why it works.

If you are trying to figure out whether your QMS approach is on the right track, a 30-minute regulatory strategy call is a good place to start. We will look at your pathway, your submission timeline and your current setup, and tell you honestly where the gaps are.

Choosing an eQMS for a Medical Device Startup