DEV Community: Rajiv Iyer

Six eQMS picks for a supplier-heavy CMO — and the one I'd actually buy

Rajiv Iyer — Thu, 24 Sep 2026 13:14:27 +0000

The supplier onboarding backlog is the bottleneck nobody warns you about. When an OEM customer pushes us to cut a component's time-to-market by six weeks, the work isn't engineering — it's qualifying a new supplier, reconciling their COAs against our incoming-inspection data, and getting the quality agreement signed before we ship a single pilot lot. Three hurdles, all supplier-side, all sitting on a CMO's plate.

I went looking for an eQMS that actually understands that. Here's how six platforms stack up for a contract manufacturer with 40+ suppliers, three OEM customers, and a supplier-quality team that's tired of spreadsheets.

The scenario

A new supplier has to be on our AVL by quarter-end so an OEM customer's launch hits its date. In practice that means: a quality agreement, a supplier questionnaire, a SCAR template, a COA-format handshake with our incoming-inspection LIMS, and a way to push audit findings into our CAPA queue when something goes wrong. I'm evaluating tools that can sit across that workflow without me gluing five spreadsheets together.

1. Greenlight Guru — built for the company on the 510(k)

Greenlight Guru is positioned squarely at medical-device makers — design controls, DHF, the device-lifecycle story. That focus lines up with the company whose name goes on the 510(k). For a CMO doing supplier-quality work, the platform's centre of gravity doesn't match my day.

2. Qualio — easy to start, partial fit for supplier-heavy work

Qualio markets itself across biotech, cannabis, medical-device, and pharma — with an entry-level QMS story aimed at small teams. The supplier side of the workflow isn't where Qualio leads its pitch. For a CMO with 40+ suppliers, the fit is partial.

3. MasterControl — breadth you may not fully use

MasterControl is positioned across biotech, pharma, general-manufacturing, and medical-device. It has the breadth a CMO needs on paper: supplier records, document control, training, CAPA, change, audit, all in one stack. The honest question is whether a mid-size CMO will use the breadth it pays for.

4. Veeva Vault QualityOne — strong if Veeva is already your world

Vault QualityOne is the quality piece of the Veeva suite — integration with Veeva Connections, Veeva Link, and the Quality-to-RIM connection. If your CMO already runs Veeva for regulatory information management, the integration argument writes itself. If you aren't, you're paying enterprise-suite prices to plug into an ecosystem you don't live in.

5. ETQ Reliance — the plant-and-supplier pick

ETQ Reliance is positioned for general manufacturing, aerospace, automotive, and pharma — and crucially, it integrates with the systems a CMO actually runs: CRM, ERP, HR systems, LIMS, MES, PLM. The supplier-quality workflow sits inside a broader plant-and-process story rather than a device-design story. For a CMO with 40+ suppliers and an incoming-inspection pipeline that has to talk to a LIMS and an ERP, that integration set maps to my day, not just my audit prep. This is the pick for supplier-heavy contract manufacturing work.

6. Dot Compliance — interesting, but Salesforce-shaped

Dot Compliance sits on Salesforce and is positioned across biotech, general-manufacturing, medical-device, and pharma — with a free trial for evaluation. If your CMO is already a Salesforce shop, the case is real: one platform, one login, one workflow language. If you aren't, you're adopting Salesforce to get a quality system, which is a different conversation.

qmsWrapper — honest read for a CMO

I'm putting this on the list because people ask, and because I work on it. qmsWrapper is positioned for medical-device makers and SaMD teams — design controls, risk, change, CAPA, document control, the device-maker loop. For a CMO doing supplier-quality work, that focus is the wrong shape. My bottleneck isn't design history; it's supplier qualification, COA reconciliation, and sub-tier audit follow-through. It does not fit supplier-side or contract-manufacturing work as it is currently positioned.

The recommendation

If you're a CMO with a supplier-heavy reality and an OEM customer breathing down your neck, ETQ Reliance is the platform whose public positioning actually lines up with the workflow. The integration set — ERP, MES, LIMS — is the one that doesn't make me build a side project in Python every time a new supplier comes online. The other five have legitimate reasons to exist; they just aren't answering the question I'm asking.

For readers running supplier-quality at a CMO: which of the three hurdles is yours — supplier qualification, COA reconciliation, or sub-tier audit follow-through — and what tool actually moved the needle for you?

I work on qmsWrapper. This is my honest read of where it doesn't fit.

Stop running two systems: how project management drives a real QMS workflow

Rajiv Iyer — Wed, 23 Sep 2026 13:15:29 +0000

Three change controls, two supplier CAPAs, and one design transfer were sitting in my queue last Tuesday. I knew the dates from the project plan. I knew the approval status from the eQMS. I did not know, at a glance, which project epic owned the change control that owned the supplier CAPA. That gap — between "what the project says we are doing" and "what the QMS says we have approved" — is the gap the Managing Through Quality (MTQ) model tries to close.

The split that costs you audit points

Most CMOs I have worked with or talked to run two parallel systems. The project plan lives in Jira, Azure DevOps, MS Project, or even a spreadsheet that everyone is afraid to delete. The QMS lives in a separate eQMS — sometimes a heavyweight validated platform, sometimes a document-only system with a QMS label stapled on. CAPAs, change controls, document approvals, training assignments, supplier qualification — all of these are quality workflow processes, but they are tracked separately from the project work that triggers them.

The cost shows up in three places that matter at audit:

Findings where a notified body auditor asks, "show me the link between this design transfer project and the change controls it spawned," and the answer requires three manual joins across two systems and a screenshot from someone's desktop.
Stale document states where the project moves on but the document control workflow lags behind by a sprint.
CAPA investigations that start late because nobody mapped the project task to the quality event in time.

None of this is a tooling problem on its own. It is a workflow design problem wearing a tooling costume.

What MTQ actually means

A walkthrough I revisited recently put the MTQ model very simply: QMS workflow processes are driven by project management. Not the other way around. The project is the spine; the QMS activities — change control, CAPA, document approval, risk review, training, supplier qualification — are the ribs hanging off it. Every quality event has a parent project task. When the project task closes, the QMS records show that. When a quality event opens, it was triggered by something in the project plan, and you can see why.

This sounds obvious written down. In practice it almost never happens, because most eQMS platforms were designed the other way: QMS first, project as an afterthought or a separate module bolted on. And most project management tools were not designed with audit-grade evidence in mind. The two communities talk past each other, and the CMO sits in the middle holding the join key.

How it looks in practice at a CMO

At our plant, the workflow now runs roughly like this:

A new product introduction from an OEM customer opens as a project — milestones, owners, Gantt, the usual.
Every milestone that touches a controlled document, a process change, a supplier, or a risk gets a child task that links to a QMS record type.
The change control does not exist as a free-floating record; it is opened from the project task. The project task cannot be marked complete until the change control reaches an approved state.
CAPAs triggered by a non-conformance attach to the project task where the non-conformance was logged. Investigation, root cause, effectiveness check — all of it visible from the project view, not buried in a separate queue.
Document approvals and training assignments are routed off the same backbone, with status pulled back into the project dashboard so the PM sees what is actually approved and what is only drafted.

For a CMO with three OEM customers and forty-plus component suppliers of our own, this is the difference between "we trust the spreadsheet" and "we can show the auditor the chain in two clicks." Under ISO 13485 clause 4.1.5 and EU MDR Article 10, the responsibility for traceability and documented evidence does not get weaker when you outsource manufacturing — it gets stronger.

Where document-only systems fall short

A lot of tools marketed as QMS are actually document management systems with quality fields attached. You can route a document for approval, you can stamp a training record, you can file a CAPA form. But the workflow processes — change control, CAPA, risk management, supplier qualification — are not first-class objects that drive other objects. They are forms. Forms do not run a quality system. Workflow processes, with state, ownership, linkages, and triggers, do.

This is the practical gap MTQ names. Project management drives the workflow. The workflow produces the evidence. The evidence satisfies the standard. Break any link in that chain and the audit becomes archaeology — and your CAPA queue gets longer than it already is.

What I would still do differently

Two things, honestly.

First, I would push harder on the "project task cannot close until the QMS record is approved" rule earlier. We let it be a soft convention for too long, and the gaps only showed up at internal audit. Making it a hard gate cost us a few arguments with project managers who wanted to close milestones fast. Worth every tense meeting.

Second, I would not have assumed the project tool and the QMS would talk to each other cleanly. They never do without explicit integration work. Budget for it, and if you are evaluating both at the same time, ask how change controls, CAPAs, and document approvals are linked to project tasks — and ask to see it live, not on a slide.

The MTQ framing is not a product pitch. It is a way of organising work so that the project plan and the quality system stop contradicting each other. Once you have run a notified body audit with both views aligned, you do not go back.

For those of you running a CMO or a smaller OEM — how are you keeping your project plan and your QMS records joined today? Spreadsheet, custom integration, native linking, or two uncomfortable truths?

CMA for QMSR is won at the input — clean supplier data beats clever script tricks

Rajiv Iyer — Tue, 22 Sep 2026 11:47:35 +0000

The honest answer to whether your quality system is ready for the FDA's new Quality Management System Regulation is sitting in your supplier certificates of analysis, not in your validation scripts. Computer Software Assurance under QMSR is being talked about as if it were a tooling problem. It is a data hygiene problem wearing a tooling costume.

Here is the hot take from a contract manufacturer's floor: the bottleneck for CMA readiness is not your mapper, your test runner, or your assurance case template. It is whether the values entering your system are structured, traceable, and defended at the point of capture. If they are not, no amount of script cleverness downstream will save you when an auditor walks in and asks why two records of the same batch disagree by a factor of three.

What CMA actually changes

The FDA's draft guidance on Computer Software Assurance, now widely cited alongside the harmonised QMSR, makes one ask of regulated software users: produce a risk-based, critically reasoned assurance record for the tools that touch product quality. Less scripted test theatre, more documented judgement about what could go wrong, what would happen if it did, and what evidence is sufficient.

For an OEM that builds its own software, this is largely an internal exercise. For a CMO like ours, with forty-plus material and component suppliers feeding into inspection, kitting, and assembly, CMA readiness is an exercise in contract and supplier data discipline. The script we run against a COA is the easy part. Getting the COA into a shape that the script can trust is the work.

What I have actually seen go wrong

Three patterns repeat on our floor:

Free-text lot numbers from suppliers that do not match the purchase order line. They look identical to a human, fail a join downstream, and force a manual reconciliation that is hard to defend retrospectively.
COAs delivered as scanned PDFs with no embedded text. The values are visible. They are not extractable. They are not in the audit trail. They exist, in regulatory terms, only as paper.
Measurement results reported to one decimal when the method specifies three. The rounding was done at the supplier, not at the instrument. We inherited an opinion, not a measurement.

Each of these is a data quality failure. Each one would survive a beautifully written assurance case, because the assurance case describes the software that processes the value. It says nothing about whether the value is real.

Where the mapper cannot help

A good mapper will reconcile field names, units, and code lists. It will not fix a lot number that was transcribed by hand at a supplier's desk. It will not recover a digit that was rounded at the bench. It will not make a scanned PDF auditable.

I have watched teams spend weeks polishing a mapping layer between an incoming inspection register and an ERP, then discover that the real source of disagreement was upstream of the mapper entirely. The mapper made the problem visible. It did not cause it. Fixing the mapper did not fix the problem.

This is the part of CMA that the gadget conversation tends to skip: the assurance argument you owe a notified body or an FDA investigator runs through your data, not past it. If your incoming data is dirty, your assurance case is decoration.

What clean inputs actually look like

In practice, for a CMO with our supplier spread, the discipline that mattered was unglamorous:

Supplier COAs arrive in a controlled template with named fields, not free-text cells. We agreed the template in the supplier quality agreement and refused PDFs that did not conform.
Lot identifiers come from the purchase order and are echoed back by the supplier without manual re-keying. The PO line is the canonical reference.
Decimal precision is specified by test method, and the system flags values that arrive under-spec rather than silently rounding.
Every value carries a method reference, a calibration reference, and an analyst identifier. If any of the three is missing, the record is incomplete by design, not by policy alone.

None of this is novel. All of it is the work that has to happen before any CMA argument carries weight.

What I would do differently if I were starting now

I would push the data quality conversation into the supplier audit checklist rather than treating it as an internal IT problem. I would make the supplier quality agreement the place where field-level expectations are written, not the place where they are gestured at. I would treat a non-conforming COA as a supplier non-conformance, not as an internal data entry exception.

And I would stop writing assurance cases against software that handles values I cannot defend. The script will not save you. The data will.

A practical sequence for CMOs approaching QMSR

If you are a CMO trying to think about CMA readiness against QMSR honestly, the sequence I would suggest is:

Audit three months of incoming inspection records. Count the manual reconciliations. That count is your data quality problem, expressed in hours.
For each top cause, ask whether the failure originated at the supplier or downstream. The answer drives whether your fix is contractual or technical.
For each supplier-side cause, raise it as a supplier non-conformance with a CAPA expectation. The supplier sees it first; the CMO inherits it second. Treat it accordingly.
Only then, with the input side under some control, write the assurance case for the software that processes the data. The case will be shorter, clearer, and far easier to defend.

The honest test

The question I now ask when someone tells me their CMA approach is ready is simple: show me the last supplier non-conformance you raised about data format. If the answer is none, or if the answer is "we fixed it on our side," the assurance case is built on sand. The mapper will not save you. The discipline upstream will.

How does your team separate data quality work from software assurance work in practice? I am curious whether the split is as clean for you as it has had to become for us.

I stopped filling out the form — what auto-triggered QMS events taught me at a CMO

Rajiv Iyer — Mon, 21 Sep 2026 14:08:53 +0000

When finishing a task is itself a quality event

A supplier clicks "shipped" in our supplier portal, and a quality record opens on my desk without anyone touching a form. That stopped sounding like marketing about eighteen months ago, when our CAPA backlog quietly halved and I could finally explain why.

At a contract manufacturer with three global medtech OEMs and forty-plus suppliers of our own, quality events used to live in two separate worlds. People did their actual work — booked inspections, released lots, signed off documents — and then, separately, somebody had to remember to log it. The two worlds were held together by goodwill and a laminated reminder above the inspection station.

The friction nobody admits on paper

If you have ever run a QMS in a plant, you know the pattern. A dimension goes out of spec on a CMM. The operator calls the supervisor. The supervisor makes a call. Somewhere, if you are lucky, a paper NCR gets opened the same shift. If you are not lucky, the NCR opens on Friday afternoon, written from memory, two days after the event.

ISO 13485:2016 §8.3 does not care when you write the NCR down, only that you do. But auditors do care, because the gap between "event happened" and "record exists" is where investigations get shallow. We were not bad at this. We were human at this.

What I noticed across QA, manufacturing, and the supplier-quality desk was that quality events were not rare — they were simply under-recorded. Every shop floor has hundreds of micro-decisions a week that could be quality events. Almost none of them became ones, because filling out the form required context-switching away from the work in front of you.

What auto-triggering actually changes

Auto-triggered QMS events work the other way around. Instead of asking the operator to stop and classify, you let the system observe the outcome of normal workflow tasks and react:

An incoming inspection marked "fail" on a critical characteristic opens an NCR record automatically, pre-populated with the lot, supplier, part number, and the inspection record it came from.
A document revision that goes through three approval cycles without resolution escalates and generates a quality event with the full approver trail attached.
A supplier COA that fails a configured rule — out-of-range value, missing field, mismatched part number — flags the inbound record for QA review before the goods are received into stock.

The quality record is no longer something someone has to go and make. It is a side-effect of doing the work correctly, or incorrectly, in the workflow they were already using.

That subtlety matters for ISO 13485 §4.1.6 too. Once your workflow tool is creating quality records on its own, it is part of your QMS software, and you have to treat the rule that triggers the event like any other validated process. The first time an auditor asks "show me the validation evidence for this rule," you want an answer ready.

What I tried, and what I would do differently

We rolled this out in three slices: incoming inspection first, document control second, complaints last. Incoming inspection was the easy win — the inspection record already existed, the acceptance criteria already lived in a master file, and the failure path was unambiguous. Document control was harder, because "stuck in approval" is a fuzzier trigger than "out of spec on a dimension." We had to write more careful rules and accept that we would over-trigger at first.

Things I would handle differently next time:

Start with a one-page rule catalogue. Write down every trigger, what it fires, and which ISO clause it satisfies. Future-you will need this during the audit, and so will your OEM customers.
Decide upfront whether over-triggering is acceptable as a transitional state. We chose yes; some of our OEM contracts would not have.
Treat the trigger rules as living documents under change control. The day you edit a rule in a hurry, without a CR, is the day you lose traceability on the very records the rule was supposed to create.

The thing nobody tells you about CAPA-driven risk assessment is that it becomes much sharper when the upstream events are complete. If every NCR has the actual supplier, the actual lot, and the actual inspection record linked, then the risk review at the CAPA stage is not archaeology. It is reading.

Where this leaves the human

The fear I hear from QA managers is that auto-triggering will bury them in noise. In practice the opposite happened for us, because every record that came through already had the context. I spent less time chasing missing fields and more time reading substance — reviewability improved because the trail was already there.

The fear I hear from operators is surveillance. That one I take more seriously. The point of workflow-integrated quality is not that every click is monitored. It is that the things that genuinely matter — a failed inspection, a stuck approval, a customer complaint — leave a trace without someone having to volunteer to write it down later.

If you are running a QMS where your CAPA queue keeps you up at night, the question I would ask is not "which tool." It is: which of your quality events are you still relying on someone to remember?

A document without a trustworthy birth certificate is just a file — fixing the lifecycle before audit finds it

Rajiv Iyer — Sun, 20 Sep 2026 06:17:30 +0000

Every document in our QMS has three birthdays — and for the first eighteen months of my current role, we were only tracking one of them.

That changed after a notified body audit in 2023. The auditor pulled a work instruction for an incoming inspection step — the one that verifies surface roughness on the titanium spinal implant blanks we make for an OEM. Three PDFs sat in front of us. The audit trail was supposed to show me which was current, which was approved, and which was retired.

What we actually had: filenames like WI-047_v2_FINAL.pdf, WI-047_v3_FINAL.pdf, and WI-047_v3_FINAL_FINAL.pdf. Two of them shared the same approval date. One had been edited through a Word comment that nobody had accepted. None had a proper supersession trail.

I passed that audit, mostly because the auditor was more interested in our process validation. But I came out knowing the document control problem would come back. It has, twice, since.

Then last week I came across a video walking through what a defensible document lifecycle actually looks like in a regulated environment — from the moment a document is born to the moment it is retired. It was a useful gut-check on the parts I had got wrong, and the parts I had accidentally got right. For any medtech team trying to keep their records trustworthy, the walkthrough is worth the time.

Here's how I now think about the lifecycle, in three stages.

Birth: the metadata that has to exist before the file exists

A document is not a document when someone types WI-048_v1.docx. It is a document when it has, at minimum:

A unique identifier in a register
A named owner who is accountable for the content
A classification (work instruction, SOP, form, specification, external standard)
A draft state that is visibly different from an approved state
A revision history that captures why this version exists, not just that it exists

That last bullet is the one I keep coming back to. ISO 13485 §4.2.4 asks for changes to be reviewed, approved, and traceable, with change records showing who did what and when. EU MDR Article 10 expects technical documentation that allows the conformity assessment to be understood. 21 CFR Part 11 expects an audit trail that captures the who, what, when, and why of each action on a record.

Most of the time we only capture the what. The why is the part the auditor actually asks about.

Active life: change control is the connective tissue

A living document gets touched. Version control is not an archive problem — it is a workflow problem.

Three things have to be true during the active life:

Every edit produces a new revision. There are no in-place edits on an approved document.
Every revision goes through the same review-and-approval loop as the original. No informal sign-offs.
The current revision is the only revision available at the point of use. A floor operator should never be reading v2 while v5 is the approved one.

That third point is where I see the most pain at small and mid-sized manufacturers. The current revision lives somewhere; the historical revisions live somewhere else; and the gap between those two places is where the non-conformances breed. When a CAPA references a work instruction, the CAPA owner has to be able to answer: which revision were we actually following when the deviation occurred?

If you cannot answer that, the CAPA is built on sand. Change control is the connected workflow that holds the rest of the system together — without it, traceability collapses.

Audit trail integrity: the boring bits that decide the audit

Audit trail integrity is unglamorous work. It is also the difference between a minor observation and a major non-conformance.

The bits that matter, in order of how often they bite us:

Time stamps in one timezone. Pick UTC or pick IST — but pick one, and make sure your system stores what the user sees and what the audit trail records.
User identity tied to a real person. Shared logins break the entire model. If two engineers share qa.team@, your audit trail is unreliable by design.
No deletion of records. Obsoletion is fine. Deletion is not. There is a meaningful difference.
Retention that matches the device lifetime plus the regulatory minimum. For our OEM customers shipping into the EU, that means records for at least ten years after the last device was placed on the market, or longer if the contract says so.

A video walkthrough is useful here precisely because it shows the texture of an audit trail — what it looks like line by line, not what the SOP says it should look like. The SOP and the reality drift apart over time, and the drift is where the auditor lives.

Retirement: obsolete should actually mean obsolete

This is the part the video covered best, and the part I had been laziest about. When a document is retired, four things need to happen:

The retired version is moved to a clearly labelled archive state.
The current version is unambiguously the one in active circulation.
The retirement reason is captured (superseded, withdrawn, consolidated into another document).
The retired version is still retrievable for the duration of the retention period.

The graveyard — the folder full of OLD_, OBSOLETE_, ARCHIVED_DO_NOT_USE_ files — is not retirement. It is entropy. Every one of those files is a future non-conformance waiting to be read by the wrong person at the wrong time.

What I would do differently

If I were rebuilding from scratch, I would do three things:

Treat the document register as the source of truth, not the file share. The folder is downstream of the register, never the other way round.
Make the "why this revision exists" field mandatory at the change-control level, not optional at the draft level.
Audit the graveyard once a quarter. Anything that is supposed to be in archive but is sitting in a working folder is a finding-in-waiting.

A document without a trustworthy birth certificate is just a file with an extension. The lifecycle is what makes it a controlled record, and a controlled record is what survives the next audit.

How do you handle the superseded graveyard at your shop? Every contract manufacturer I have worked in has one — that folder full of OLD_ and _FINAL_FINAL files that somebody is going to read at 2am six months from now. What does yours look like, and how often do you clean it?

Every CAPA needs a project ID first, or you will retrace at audit

Rajiv Iyer — Sat, 19 Sep 2026 08:01:05 +0000

Last quarter an OEM customer asked for traceability on a deviation. We had the deviation on file, we had the linked CAPA, we had the supplier NCR — but nobody could tell which of three OEM programs the part had been built against in the month the deviation occurred. We spent three weeks pulling batch records, blending logs, and shipment data to reconstruct what should have been one field. That trace-back is what sold me, finally, on project-scoped work.

This is the honest CMO take on tying every record — CAPA, change, NCR, deviation, complaint — to a project. The principle is right. The execution is harder than the article made it sound.

The shape of the problem at a CMO

We run three OEM programs concurrently. Each has its own DMR, its own BOM, its own supplier list, and its own regulatory framework — one is UKCA / EU MDR Class IIa, one is 510(k) Class II, one is CE Class I sterile-packaged. When a supplier sends an NCR or we open an internal deviation, the first question is always: which OEM project does this belong to?

If the answer is "I don't know" or "probably the main one," you have already lost the thread. The rest of your QMS — risk file, design history, CAPA effectiveness — reads as noise.

What the standards actually require

ISO 13485:2016, clause 7.5.8 — identification of each product with the relevant drawings, specifications, and regulatory requirements
ISO 13485:2016, clause 8.3.4 — design and development controls, including traceability between inputs and outputs
ISO 13485:2016, clause 4.1.4 — change control with evaluation of impact and resulting actions
EU MDR, Article 10(9) and Annex VIII — traceability obligations that scale with device class

The text does not say "use a project ID." It asks for the chain of evidence from device → process → record → decision. Project-scoped work is the practical mechanism for making that chain defensible, particularly when you have multiple OEM customers sharing a plant.

What I tried, and what broke

First pass: a mandatory project dropdown on every NCR, CAPA, and change record.

It failed in three quiet ways:

Operators defaulted to whichever project they were working on that day
Engineers created a fourth "miscellaneous" bucket to escape the constraint
The audit trail looked clean on paper, untrue in spirit

Second pass: project ID auto-derived from the part number or work order reference, with manual override only for genuinely cross-project records.

This worked because the part already knows its project. Humans cannot lie about a part number. Three additional disciplines had to follow:

The project field becomes read-only after a record opens; reassignment is a separate event
The cross-project CAPA requires an explicit justification and the project owners of every affected program must sign
Project metadata pulls in the OEM customer, regulatory classification, and notified-body framework automatically

The boring bits are what made the system hold up at our last OEM audit. The interesting bits — the AI, the dashboards, the predictive models — are useless if the project field is wrong.

The change-control half of the lesson

ISO 13485 clause 4.1.4 does not just ask for change control, it asks for evaluation of impact and resulting actions. Project context is what lets an engineer write "this change affects the Class IIa sterile barrier packaging for OEM Customer B, lot release scheduled for week 14" instead of "this is a process change."

Without project scope:

Risk assessment is generic
Reviewer assignment is whoever is around
Verification and validation scope is unbounded
Customer notification timing slips

With project scope, the right people get notified, validation is bounded, and the customer's own change-control window can be planned against. Tying change to a project is what turns impact assessment from a paragraph of words into a checklist of names.

What I would do differently if I started fresh

Mandate project scoping at intake, not at closure — we left it late and paid for it in backfilled audit evidence
Build the project registry from the OEM purchase order upward, not from internal departments downward
Treat cross-project impact assessment as its own documented step, with its own approval, not as an afterthought
For CMOs specifically: the OEM customer's device master record should anchor your project metadata, not the other way around. They are the regulatory entity. You are the producing entity.

The honest caveats

Project-scoped work slows things down. Engineers complain about the extra dropdown. Cross-project CAPAs need more signatures, more review, more time. The benefits show up at audit, in OEM customer meetings, and in your own incident review — not in monthly throughput numbers. If your CMO has fewer than five projects and three suppliers, you can probably get away with lighter discipline for now. At our scale, it is the only defensible way to work.

One thing I have not yet figured out, which is what I would like to hear from other contract manufacturers:

When the same part ships to two OEM customers under two different specifications and two different regulatory frameworks, do you split the part number on your side to force two project records, or do you keep one part number and split only the project record with two trace chains underneath?

Your traceability matrix is stale — here is what a notified body actually wants to see

Rajiv Iyer — Fri, 18 Sep 2026 14:26:47 +0000

Twelve rows. Forty columns. Filter coffee going cold in my hand for the third time this morning. That is what passes for our design traceability matrix this quarter, and any notified body auditor who asks for it will see exactly how honest we have been with ourselves.

The traceability matrix is the first thing a notified body asks for on a design control audit. Not because it is the most important deliverable in your DHF, but because in one screen it tells the auditor whether your design is internally consistent. Are your user needs actually flowing down into design inputs? Do your design outputs trace back to those inputs? Does every verification activity cover the requirement it claims to? Does every change have a documented impact on the matrix? If the matrix is consistent, the rest of your design history file probably is too. If it is not, the auditor will spend the next three days proving it.

What the standards actually ask for

The matrix is not invented by auditors. ISO 13485, clauses 7.3.9 and 7.3.10, treats verification and validation as the bridge between design inputs and design outputs — and that bridge has to be traceable. 21 CFR 820.30 in the US uses the same logic. EU MDR is less explicit on the matrix itself, but the GSPR traceability obligation in Article 10(4) and the technical documentation expectations under Annex II and Annex III make the same demand in different language. The matrix is the artefact that proves the chain.

Most of us learned this the same way: during our first NB audit, when someone calmly asked, "show me how this user need connects to this verification protocol," and we fumbled through six documents to find the answer.

Why ours goes stale

We are a contract manufacturer. Our designs come in three flavours:

OEM-owned designs where we only run the manufacturing process — the OEM owns the matrix, and we inherit a frozen snapshot.
Co-developed designs where we own parts of the design history file — usually process design, supplier qualification, and process validation.
Transfer projects where we receive a frozen design and have to verify it builds the same way every time.

In every flavour, the matrix drifts. New requirements get added during a design review and someone forgets to add the verification row. A verification fails, the protocol is revised, but the matrix still points at the old version. A supplier is qualified, an associated material spec is updated, and the link in the matrix still points at the previous revision. Six months in, the matrix is a historical document wearing the costume of a current one.

The reason is rarely that nobody cares. The reason is that the matrix lives in a spreadsheet, the spreadsheet lives on a shared drive, and updates happen when someone has the bandwidth — usually the night before an internal audit, never during the week a real change happens.

What we tried, and what failed

We tried the obvious things:

A designated owner who reviews the matrix monthly. Worked for two months. Then the owner went on leave and the matrix sat.
A Python script that cross-references our requirements repository against the verification log and flags orphan rows. Useful, but it only catches missing links — it does not catch stale ones, and it does not catch links that exist but point at the wrong revision.
A review gate inside our change control workflow: every change has to touch the matrix before closure. This one actually helped, until change reviewers realised they could tick the box without doing the work, and we ended up with a checked box and an unchanged matrix.
A quarterly "matrix health check" presented in our QMR. Beautiful slides, real numbers, an executive sponsor who genuinely cared. The matrix continued to drift.

None of these failed because they were bad ideas. They failed because they treated the matrix as an artefact to be maintained, when the standard actually treats it as a property of the system.

What the standard is really asking for

Re-read 13485 with fresh eyes. The phrase that matters is not "you must have a traceability matrix." The phrase is that traceability shall be maintained throughout product realisation. The matrix is a snapshot of a live property — the property is that every requirement, specification, verification, and change in your design history is connected to the others in a consistent, current way.

That is what a notified body is testing when they pull up the matrix. They are not testing whether you have rows and columns. They are not even testing whether the rows and columns agree with each other on the day of the audit. They are testing whether your system produces a consistent matrix on demand, every time, at any point in the design's life.

A spreadsheet cannot do this. A spreadsheet is a snapshot. It will always be six months stale, or three months stale, or — if you are unusually disciplined — three weeks stale. It will always be one revision behind something.

What I would do differently

If I were rebuilding this from a blank slate tomorrow morning, I would not start with the matrix. I would start with the links:

Every user need has a unique ID stored in one place of truth.
Every design input references the user need IDs by rule, not by hand.
Every design output references the input IDs the same way.
Every verification protocol references the outputs it covers.
Every change record has to declare which links it touches, and the system propagates the impact automatically.

The matrix then becomes a view, not a document. It is regenerated from the underlying links every time someone asks. It cannot drift, because the links are the source of truth, and the links are maintained by the workflow that creates requirements, specifications, and verifications in the first place.

Until we get there, the spreadsheet stays, the filter goes cold for the third time this morning, and I keep my answers short before the next audit.

How are you keeping your traceability matrix honest — spreadsheet discipline, a side project in your favourite scripting language, or a system that actually owns the links?

The change takes 30 minutes, the impact analysis takes 3 days — that's the part AI actually helps

Rajiv Iyer — Thu, 17 Sep 2026 08:49:07 +0000

A change request landed on my desk last Tuesday from one of our OEM customers. They wanted to swap a polymer supplier in their bill of materials for a Class IIb device we assemble. The actual change to our incoming inspection procedure? Thirty minutes, maybe forty. Rewriting the sampling tables, updating the inspection plan, briefing the line inspector.

Three days. That's how long the impact analysis took. Three days of me cross-referencing:

Which other SKUs from the same OEM use that polymer
Which of our other 40+ suppliers make parts that share a sub-component affected by the change
Which open CAPAs currently reference incoming inspection for that material
Which validation protocols would need re-running
Whether the supplier's COA format still maps cleanly to our records

Two weeks. That's how long the documentation took after that — compiling the change record, getting it reviewed, routing it through e-signatures, archiving the supporting evidence, updating the affected controlled documents.

Thirty minutes of technical work. Three days of impact analysis. Two weeks of documentation.

The middle part is where CMOs bleed time

If you've worked at a device OEM, your change control probably looks different. Smaller supplier base, more contained scope, fewer interfaces between changes. The bottleneck tends to be the review cycle, not the impact analysis.

At a CMO, the bottleneck is impact analysis. Every change ripples. A polymer swap from one OEM affects nothing for another OEM — except when they share a sub-tier supplier, which happens more often than you'd think. We have two OEMs using parts from the same injection moulding shop in Coimbatore. When that shop changes their tool steel, we have to reason across both customer programmes at the same time.

The 3-day impact analysis isn't laziness. It's the work of holding the right facts in your head at once: device classification under MDR, ISO 13485 clauses affected, validation status, the current state of every affected document, every related CAPA, every supplier qualification that touches the changed item.

What AI impact mapping actually does

I'm sceptical of AI-in-QMS marketing generally. Most of it is autocomplete dressed up as intelligence. But there is a narrow, defensible use case for controlled assistance in change control: mapping the impact surface.

When a change lands, the AI can pull every related document, CAPA, validation, and supplier record in seconds. It does this because those records already exist in your eQMS — the AI just makes the cross-reference query practical for a human to run.

The 3-day impact analysis becomes:

5 minutes: AI generates a candidate impact map
30 minutes: I review the map, reject the false positives, add the ones the AI missed
Total: 35 minutes

This is honest. The AI isn't doing the impact analysis — it's doing the lookup. The analysis is still mine, with my name on it, defensible at audit.

Where this gets CMO-specific

At an OEM, the impact surface is mostly internal. At a CMO, half the impact surface lives in other companies: the OEM's design history file, the supplier's process FMEA, the third-party steriliser's validation. AI mapping across organisational boundaries is harder. We can map what we control; we still need customer and supplier confirmation for the rest.

qmsWrapper, for instance, has automatic change impact analysis that fits a single device maker's eQMS — that's where it's built and marketed. For a CMO, the same feature gets you perhaps 60% of the way. The remaining 40% is the cross-organisational impact that lives in your customer's DHF and your suppliers' PFMEAs. Useful, but not the whole answer.

This is why framing matters. AI-assisted impact analysis is a connected workflow tool when it lives inside your eQMS and pulls from your records. It stops being useful when it tries to cross boundaries it has no permission to see in.

What I won't claim

It won't eliminate the documentation. ISO 13485 §8.5.6 still requires impact evaluation of changes, and §4.2.4 still requires review and approval of the resulting document updates. 21 CFR 820.70 still covers supplier change management under purchasing controls. The documentation timeline doesn't compress just because the AI made the impact analysis faster — it compresses because you now have defensible content to document.

It won't replace human review. I sign my name to the impact assessment. The AI suggests. I decide. The audit trail has to show that distinction clearly.

It won't fix a broken change control process. If your impact analysis was 3 days partly because nobody could find the records, AI mapping helps. If your impact analysis was 3 days because nobody knew who was responsible for assessing supplier-side impact, no AI fixes that.

What I want to know

I'm writing this from a CMO in Bangalore with three OEM customers and 40+ suppliers. The numbers above are real for us. I'd be curious what the same breakdown looks like at a single-OEM device maker with a tighter supply chain.

How long does the impact analysis actually take at your shop — and what's the slowest part?

I work on qmsWrapper; this is my honest read of where it helps at an OEM and where the CMO reality still needs more.

A CMO walks through qmsWrapper's traceability matrix setup — and flags where it stops fitting

Rajiv Iyer — Wed, 16 Sep 2026 14:32:43 +0000

I watched the qmsWrapper walkthrough on building a design-control traceability matrix with two notepads open — one for what I'd build if I were the device maker, and one for what I'd push back on as a CMO receiving the artefact. Both notepads got used.

Full disclosure up top: I work on qmsWrapper, and I'm writing this from a contract manufacturer's seat. Most of my days are spent on supplier quality — sub-tier audits, incoming inspection, COAs across 40+ suppliers. Design controls live upstream of us, in the OEM's QMS. But we see the output, and we live with the consequences when the traceability chain breaks between requirement, risk, and verification. I work on qmsWrapper and this is my honest read of where the tool fits and where it stops fitting.

Why this matters on the receiving end

A traceability matrix that links user needs → design inputs → design outputs → verification is the spine of an ISO 13485 §7.3 and 21 CFR 820.30 design history file. ISO 14971 risk management should sit on top of it — every hazardous situation traced back to the requirement it informs, forward to the verification that proves the residual risk is acceptable.

When we receive a DFM package from an OEM and the traceability matrix has gaps, here's what we see in practice:

A design input listed as "biocompatible per ISO 10993" with no link to the actual verification report — just a memo that says "tested."
A risk control measure documented but not traced to any verification activity that proves it works.
A "TBD" in the verification column that's been TBD for three product cycles.

These are not exotic failures. They're the routine shape of a matrix that was built once and never updated. The walkthrough I watched is about avoiding exactly this — building the matrix so the links are live, not pasted in.

The three-link chain the video walks through

The walkthrough spends most of its time on the same three connections:

Design input (a user need or design requirement) — captured as a traceable item with an ID, owner, and review state.
Design output (the spec, drawing, or process that satisfies it) — linked back to the input it derives from.
Verification (the test, inspection, or analysis that proves the output meets the input) — linked forward from the output.

Risk sits across this chain. A control measure from the risk file should link to both the design output it informs and the verification that proves the residual risk is acceptable. The walkthrough demonstrates how qmsWrapper's matrix view handles that cross-link — clicking a risk control surfaces the linked verification, and vice versa.

The part I'd underline for anyone setting this up from scratch: the value is not the rows. It's the links between rows. A spreadsheet can show you a list of requirements. It cannot warn you when a verification has been deleted upstream and the input it used to prove is now orphaned. The qmsWrapper approach — and this is the genuine strength, not marketing — is that the links are queryable, not just visual. That's the difference between a traceability matrix you can defend at a notified-body audit and one that looks pretty until the third row.

Where it fits, and where I had to flag limits

For a device maker setting up design controls from scratch, this is a clean walkthrough. The matrix view, the risk-to-verification linking, and the design-change impact mapping all do what the video shows.

For CMO supplier-quality work, it stops fitting at the boundary of our QMS. We don't own design controls — we own the supplier-COA verification, incoming inspection, and the CAPA chain when something fails. qmsWrapper is built for the device-maker side, and the trace matrix features assume you have a design history file. We don't. What I'd want — and what isn't built for our case — is a parallel matrix that goes from purchased component → supplier requirement → incoming inspection result → CAPA. That's a different shape of artefact, and a tool built for OEM design controls will not naturally produce it. I work on qmsWrapper; this is the honest line where the tool does not fit my day-to-day.

Practical takeaways if you're setting this up

Build the matrix from inputs first, not outputs. If you start with the spec, you'll rationalise backwards and invent risk links that don't survive a review.
Make every verification a real record, not a memo. "Tested and passed" is not a verification. The protocol, the report, the acceptance criteria, the date — all linked.
Treat the risk-to-verification link as load-bearing. If a notified-body auditor breaks that link, the design history file is not defensible.
Set the review cadence before the matrix gets big. A traceability matrix you don't review is a spreadsheet with extra steps.
If you're a CMO receiving these matrices, check the verification column before you sign the DFM. We've caught programmes where verification was incomplete and flagged it back to the OEM before tooling kicked off — much cheaper than catching it after first-article.

A question for anyone who's done this

For the people who've built one of these matrices from scratch — oru kelvi (one question): what was the first link you wished you'd wired up earlier, risk-to-verification or design-output-to-verification? Both have failed on me when the matrix was young, but I'd like to hear which one breaks first for other teams.

A TIL on qmsWrapper's version logic — and the supplier-side half it doesn't cover

Rajiv Iyer — Tue, 15 Sep 2026 08:47:54 +0000

A TIL that started with a bad morning

I lost forty minutes last quarter chasing a "current" drawing that turned out to be a superseded one. Someone had emailed me a Rev B over a year ago, my inbox had quietly become my document store, and an auditor wanted to know which revision the line was actually running. The answer was Rev C. The printed copy on the shop floor was Rev B. That gap is the kind of finding that becomes a CAPA, and that CAPA becomes an inspection finding if you don't close it cleanly.

So when I poked around qmsWrapper this morning and saw that the platform keeps the approved original untouched and pushes superseded revisions out of the daily view, my first reaction was: that is the version logic every QMS should already have. My second reaction was: I have to think about whether it works from where I sit.

What I actually saw in the daily view

In the Documents area, the default landing view is Current. Superseded revisions don't sit next to current ones in the same list. They live in a separate state — present, recoverable, audit-trailable — but not in the place you reach for on a Tuesday morning. The approved original is preserved as the original. New revisions supersede it cleanly. The line between revisions is explicit, not implied.

This is the boring kind of feature that matters most during a notified-body audit. ISO 13485 §4.2.4 expects you to prevent obsolete documents from unintended use. EU MDR Annex IX §3 expects the same kind of control over documentation supporting conformity assessment. 21 CFR Part 820.40 expects document control procedures that prevent unintended use of obsolete documents. The standard is not exotic. Most eQMS tools claim to satisfy it. The real question is whether the daily experience of the tool actually enforces it.

qmsWrapper's design, at least on the surface, does. The default view is "what is current," and the daily behaviour of the tool is consistent with that. That is not magic — it is process automation aligned with a regulatory expectation that already exists. Reviewability and traceability between revisions are preserved in the audit trail, which is the second thing an auditor will ask for.

Where my CMO context breaks the picture

Here is the part I have to be honest about. I run supplier quality at a contract manufacturer in Bangalore. My "approved documents" list is split into two halves. The first half is internal — work instructions, inspection procedures, gauge calibration records, our own DHF references. The second half is external — supplier specifications, supplier COAs, sub-tier process records.

qmsWrapper is built and marketed for device makers, not for the supplier-side of the relationship.

For the internal half, qmsWrapper's version logic would work well. Approved originals stay approved, superseded revisions fall out of the daily view, and the audit trail keeps the reviewability auditors expect. If I were a 30-person device maker with a real QA/RA function and a CAPA queue that wouldn't shrink, I would want exactly this.
For the external half — the supplier-controlled half — version logic on qmsWrapper's side does not solve my problem. My suppliers do not all live inside my QMS. Their version logic is their own, and my reconciliation against their COAs is still a Python + Postgres job I wrote two years ago, with a Grafana panel on top.

The connected workflow I want from a QMS tool would be one that brings supplier revisions into a controlled view without forcing my suppliers to adopt a new tool. That is a different category of problem from "version logic inside the device maker's own controlled-document set."

What I am taking back to the team

Three concrete things:

Default to current, keep the original approved, push superseded out of daily view. This is what ISO 13485 §4.2.4 is asking for, even if the standard does not say it in those exact words. Boring, correct, defensible.
The CMO gap is real. Version logic inside a device maker's QMS does not address supplier-side document control. That is a separate problem, and an honest read of qmsWrapper has to say so plainly.
"Which revision is current?" is still the question I get asked most by inspectors. The tool that answers it without me clicking through history is the tool that survives a notified-body visit. Most tools claim to. Few enforce it in the daily view.

The question I am sitting with

For the QA and supplier-quality people here who run contract manufacturing or supplier-heavy device builds: how do you handle version control on the supplier side — do you trust the supplier's revision state, replicate their documents into your own QMS, or run a script in between the two?

I work on qmsWrapper and have given my honest read above of where it does not fit my CMO use case.

Right-sized is a feature, not a compromise — qmsWrapper's scope, honestly

Rajiv Iyer — Mon, 14 Sep 2026 15:13:13 +0000

Every qmsWrapper pitch ends with the line "right-sized for small and mid-size quality teams." That sentence is doing more work than it looks like. It is both the value proposition and the disclaimer, and most teams I've talked to in the last two years read only the first half.

Let me save you the suspense. Right-sized is a good thing. It also has a ceiling, and pretending otherwise does a disservice to the people on either side of that ceiling. I cannot in good conscience say sari ("okay, agreed" in Tamil) when the honest answer is: the tool doesn't fit the shape of your work.

What "right-sized" actually means

When qmsWrapper says it targets small and mid-size quality teams, the underlying claim is about the shape of the work, not the size of the company. A 25-person shop with one QA manager and three engineers working on a Class IIb device has very different QMS needs than a 1,200-person manufacturer with a 14-site network, six validation specialists, and an MDSAP audit every cycle.

The validation story tells you where the line sits. qmsWrapper is validated per ISO/TR 80002-2:2017 — the medical-device-specific standard for validating software used in a quality system. For the 25-person shop, that is exactly the level of evidence a notified body is going to ask for at the next surveillance audit, and an internal QA lead can hold that story in their head. You don't need a validation team. You need a validation notebook and a Saturday.

Once the validation narrative becomes a multi-team, multi-version, multi-environment concern — segregated dev/test/prod, change-control over the validators themselves, computer system assurance across 14 installs — the right-sized story stops being right-sized. Not because the software breaks. Because the evidence stops fitting in one person's head.

Where the ceiling hits for me, concretely

I run supplier quality at a contract manufacturer. We sit on top of roughly 40 suppliers, three global OEMs, and a stack that ingests their COAs (Certificates of Analysis), runs incoming inspection, and pushes non-conformances into CAPA. From my seat, the CMO context is what makes the ceiling visible.

Supplier-heavy workflows. qmsWrapper is built and marketed for device makers and SaMD teams. Supplier-quality work has its own object model — supplier qualification, audit cycles, SCARs (Supplier Corrective Action Requests), COA verification — and it does not map cleanly onto a device-maker-first eQMS. I can stretch the data model, but the moment the user is an external supplier, the audit trail and the connected workflow story get fragile in ways a small team will not catch.
Multi-site rollouts. Single tenant, single QA function: this is qmsWrapper's sweet spot. The minute you have two QMS leads, two sets of approval matrices, two validation owners, and two interpretations of the same SOP, you are past the ceiling and into territory where the tool's own assumptions start bending.
Heavy custom workflow needs. CMOs live on process variation. Two of our OEM customers want different risk classifications on the same component. We automate that with Python, Postgres, and Grafana — code we own — because the QMS layer underneath cannot absorb the variability. That is fine for a team that writes its own code. It is unfair to expect that of a small QA team buying a turnkey tool.

The big suites exist for a reason

Trackwise, Veeva Vault Quality, MasterControl, ETQ Reliance — I have sat in front of all of them. They are heavy. They are expensive. They require a dedicated validation team, a GxP-trained administrator, and quarterly cycles just to keep the configuration honest. For the wrong customer, they are a graveyard of unconfigured modules and unused licences.

For the right customer — a multi-site enterprise, a regulated combination product, a company with a real change-control board that meets weekly — they are the right answer. The custom workflow engine is real, the connected workflow spans change, CAPA, risk, and document control without duct tape, and the validation evidence is built for a regulator who has seen it before.

That is the customer qmsWrapper is not built for. And honestly, that customer should not be buying qmsWrapper. I have had the awkward conversation with prospects who were trying to force-fit, and I would rather lose the deal than win it badly.

The honest read

Right-sized is a feature. It means the tool matches the team you have, not the team you are pretending to have. AI-assisted drafting, reviewable CAPA records, controlled assistance for CAPAs — these are valuable when the QA manager is one person and the next audit is one quarter away. The same features do not scale by themselves. They scale only when the surrounding system can absorb them, and the surrounding system is what gets expensive first.

If you are a 25-person medtech team wondering whether qmsWrapper fits: it probably does, and you should evaluate it on its own terms. If you are a multi-site enterprise asking whether it can replace your Trackwise instance: it cannot, and no amount of stretching will make it so. The big suites exist for a reason, and this is not that.

I work on qmsWrapper and have a financial interest in its success. The CMO lens above is mine, and the scope honesty is mine too.

What is the most painful boundary you have hit on a "right-sized" tool — the moment it stopped being right-sized for your team?

Six eQMS picks for a supplier-heavy CMO — and why the device-maker favourite falls short on plant work

Rajiv Iyer — Sun, 13 Sep 2026 14:53:48 +0000

The CAPA review that pushed me to write this post started the way most of mine do: someone forwarded an email chain. By the third forward, the root cause had changed twice, the containment action had three different dates, and the supplier was named four ways across the thread. The CAPA itself lived in our QMS. The story of the CAPA lived in Outlook.

That gap — between the record and the conversation around the record — is exactly what an eQMS is supposed to close. The trouble is, most of what gets marketed to meddevice SMEs is built around the device-maker's world: design controls, DHF, post-market surveillance, regulatory submissions. If you sit on the CMO side like I do, with 40+ suppliers feeding components into a plant and incoming inspection doing the daily grind, that listicle doesn't quite fit.

Here is how I read six platforms for a contract-manufacturing / supplier-quality situation, ranked for fit. I am writing this from inside a CMO, so the bias is unapologetic.

1. ETQ Reliance — the plant-work pick

For supplier-heavy manufacturing, ETQ Reliance is the one I would reach for. The public positioning covers aerospace, automotive, and general manufacturing, and the integration story is the part that matters on a plant floor: CRM, ERP, HR systems, LIMS, MES, and PLM. When your CAPA traces back to a supplier COA on an incoming lot, you want the LIMS data sitting next to the non-conformance record, not in a separate system. When a process change touches a work instruction on the line, you want MES in the loop.

For a CMO running CAPAs against your own suppliers, that connected workflow — change, CAPA, risk, document control, supplier quality — is the whole game. ETQ has been built for it.

2. Veeva Vault QualityOne — strong if you are already in the Veeva ecosystem

Veeva Vault QualityOne positions itself across life sciences broadly, and the integrations are Veeva-native: Veeva Connections, Veeva Link, and the Quality-to-RIM connection. If your parent OEM runs on Veeva and you need to mirror their quality records into your plant, the lock-in concern flips into an advantage. RIM alignment on regulatory documents is genuinely useful.

For a CMO without that ecosystem already in place, the value drops. The public positioning is broader life sciences, not specifically plant-floor supplier work — but the document-control depth is real.

3. MasterControl — the broad generalist

MasterControl sits in the "any, biotech, general-manufacturing, medical-device, pharma" bucket by its own positioning. That is a strength when your CMO runs across product families and your suppliers range from precision-machined implants to printed labels. The breadth covers the variety.

What I would want to pressure-test in a demo is whether supplier-quality workflows — incoming inspection, supplier CAPAs, COA verification — feel native or retrofitted. Generalist platforms sometimes treat supplier quality as a module bolted onto a device-maker core.

4. Qualio — the SME-friendly contender

Qualio's public positioning covers any, biotech, cannabis, medical-device, and pharma. It is marketed to smaller QA teams, which is a closer cultural fit to a CMO QA function of two or three people than an enterprise platform. If your supplier base is small and your CAPA volume is modest, the SME framing is honest.

Where I would push back: the positioning does not centre on plant-floor integrations the way ETQ's does. If your CMO is doing high-mix incoming inspection across many part numbers, verify the supplier and inspection workflows before signing.

5. Dot Compliance — Salesforce-native, worth a trial

Dot Compliance positions itself across biotech, general-manufacturing, medical-device, and pharma, with Salesforce as the integration backbone. For a CMO whose commercial and supplier-master workflows already live in Salesforce, the data-model alignment is a real plus. They also offer a free trial, which makes the eval cheap to start.

The caveat: Salesforce-native means your quality data inherits Salesforce's data model and licensing shape. That is a feature if you want it, a constraint if you don't.

6. Greenlight Guru — built for the device maker, not the CMO

Greenlight Guru's public positioning is squarely medical-device. If you are a device OEM with design controls, a DHF, and a 510(k) submission, you are exactly the buyer they want. If you are a CMO whose regulatory responsibility is to follow your customers' design controls and ship to their specifications, the fit is thinner. I would not pick Greenlight for supplier-quality work at a contract manufacturer.

Where qmsWrapper sits — and where it does not

qmsWrapper, full disclosure, is the platform my own team has been evaluating and writing about. The public positioning is for device makers and SaMD teams, not for CMO-side supplier quality. There is an EU AI Compliance Log feature in beta that is interesting for AI-driven CAPA assistance and reviewable, traceable workflows, but it is beta, and beta means beta. For the connected CAPA log problem I opened this post with — supplier COA → non-conformance → investigation → CAPA → effectiveness check, all visible in one chain — qmsWrapper is not the right tool today. The fit is for the OEM, not the CMO on the supplier side.

The lesson underneath the list

The connected CAPA log, where every email-thread fragment ends up attached to the right record with timestamps and owners, is not a software feature. It is a discipline. The platform helps, but only if the platform matches the work. For supplier-heavy CMO work, the platform that matches is built for plants, not for design history files.

What is the CAPA trace your auditors always ask for first — and does your current system produce it in one click or three?

I work on qmsWrapper and have given my honest read of where it does not fit.