The first piece of software a lot of medical device founders buy is a QMS. Someone tells them FDA requires one, a demo looks thorough, and within a quarter the team is trying to run its entire product through Greenlight Guru or Qualio: the BOM, the part numbers, the vendor package, every screw.
The premise is half right. FDA does require a quality system. It doesn't require that a single piece of software hold your whole product.
The short answer: nearly every medical device manufacturer needs a documented quality management system, and Class II and III devices need design controls on top of it. That system is a set of processes and records, not a product you buy. A QMS tool runs those processes well; a PLM holds the product data they point to. Most startups need both.
What FDA Actually Requires Is a System, Not Software
FDA's Quality Management System Regulation took effect on February 2, 2026. It replaced the old Quality System Regulation and now incorporates ISO 13485:2016 by reference, so the FDA and international expectations finally read from the same document.
The core requirement in 21 CFR 820.1 is that a manufacturer "establish and maintain a quality management system that is appropriate for its specific device(s)." Nothing in that sentence names a tool. A binder, a shared drive with disciplined document control, an eQMS, or some combination of them can satisfy it.
The one constraint the tooling adds: if you rely on electronic records and signatures to meet those requirements, 21 CFR Part 11 applies to them. That means audit trails, access controls, and signatures that actually bind a person to an approval. It's a real reason to buy an eQMS. It's not a reason to put your BOM in one.
What Changes Between Class I, II, and III
A common assumption is that a lower device class means you can skip the quality system for now. It doesn't work that way. Class changes your path to market and how much rigor a reviewer expects; it rarely changes whether you need a quality system at all.
| Device class | Quality system required | Design controls (ISO 13485 7.3) | Typical path to market |
|---|---|---|---|
| Class I, GMP-exempt | Records and complaint files only | No | Usually 510(k)-exempt |
| Class I | Yes | Only if it includes software, or is one of five listed device types | Usually 510(k)-exempt |
| Class II | Yes | Yes | Usually 510(k) |
| Class III | Yes | Yes | PMA |
Two rows deserve emphasis. A Class II device, which is where most venture-backed device startups land, needs full design controls from the point development begins. And a Class I device with any software in it picks up design controls too, which covers a lot of connected hardware.
The timing matters as much as the class. FDA has said design controls aren't meant to cover concept and feasibility research; they generally start once you decide to develop the device for market, and they need to be running before investigational device studies. Write down where that line falls for your team. Everything you design after it has to be traceable.
What a QMS Does Day to Day
Strip the marketing off and a QMS is a set of controlled processes with records attached. Document control keeps procedures and specifications approved and versioned. CAPA tracks problems from discovery through root cause and verified fix. Complaint handling feeds postmarket surveillance and, when the criteria are met, FDA reporting. Training records prove the people doing the work were qualified to do it. Risk management, run against ISO 14971, ties hazards to the design decisions that mitigate them.
Design controls run through the QMS too: design inputs, outputs, reviews, verification, validation, transfer, and the evaluation and approval of every design change. That last one is where the QMS and the product data meet, and where most teams get confused about which system owns what.
A good eQMS earns its price on these processes. Linking a CAPA to a complaint to a risk file to a design change, with Part 11 signatures on every approval, is genuinely hard to do in a shared drive.
What a PLM Does That a QMS Isn't Built For
A PLM holds the product itself. The multi-level BOM, internal part numbers, manufacturer part numbers and approved alternates, every revision of every assembly, the drawings and files behind them, and the record of exactly which line items each engineering change touched.
That's the minutiae your engineers live in every week. Swapping an M3 screw for a different length. Moving a cell to a second supplier because the first one went on allocation. Updating the package your contract manufacturer builds from. None of that is glamorous, and all of it has to be right, because the CM builds exactly what you hand them.
To be fair to the QMS vendors: some now include BOM features. Greenlight Guru, for one, supports multi-level BOMs, routed approval of BOM item changes, and supplier tags on items, linked back to design and quality records. That's useful for traceability. The question to ask is whether it's where your engineers want to do their daily work: importing a BOM out of Onshape or KiCad, tracking alternates by MPN, seeing a line-by-line diff of a revision, and exporting a clean package for the CM. Check those against your own workflow before you assume the QMS covers it.
The two systems are built for different users. A QMS is built for the quality lead and the auditor. A PLM is built for the engineer making the change and the ops lead buying the parts. Forcing either group to live in the other's tool is how you end up with a BOM nobody trusts in a system everybody resents.
How an Engineering Change Moves Between the Two
Under ISO 13485 clause 7.3.9, every design change has to be identified, evaluated for its effect on the device, verified or validated as appropriate, and approved before it's implemented. That doesn't mean every detail of the change lives in the QMS. It means the evaluation and the approval do.
The split that works: every change gets an engineering change order, and the ECO number links both records. The PLM holds the what: the part that changed, the new revision, every assembly it affects, and the updated vendor package. The QMS holds the why and the sign-off: the impact assessment, the risk file update, the verification evidence, and the signed approval.
Take a battery change. Your preferred lithium cell goes end-of-life and you qualify a replacement from a different manufacturer. In the PLM, the ECO captures the new MPN, the BOM revision on the battery subassembly and the top-level device, the updated drawing, and the package your CM will build from. In the QMS, the design change record captures why the swap is safe: the risk assessment, the re-verification against IEC 62133, any supplier qualification, and the signatures. An auditor follows the ECO number from one to the other and finds a complete story.
The screw change gets the same treatment, just lighter. It still needs an evaluation, even if the evaluation is one sentence saying the change has no effect on safety or performance. Skipping the record is how small changes turn into audit findings. If your team hasn't settled when ECOs should start yet, the regulation answers it for you: once design controls start, every change counts.
Why Not Buy an Enterprise PLM Too
Because a startup paying for an eQMS rarely has room for a second five-figure contract. The PLM vendors that market hardest to medtech are priced for established manufacturers: Arena runs a $10,000-a-year minimum before setup, and Propel's published small-team license ranges start at $10,000 a year plus a setup fee. Both pitch PLM and QMS in one platform, which makes sense for a company with a quality department and an IT team to administer it. For eight engineers and one quality lead preparing a 510(k), it's a lot of system.
What that team actually needs from a PLM is narrower: a BOM it trusts, part numbers that mean something, a numbering scheme that survives growth, and change orders that show exactly what moved.
That's the job oroForge was built for. It holds your multi-level BOMs and product files in one place, tracks every ECO on a board from request to approval, and puts a reviewer in front of a line-by-line diff of what changed. Approving an ECO versions every affected BOM automatically, the change history shows who edited what and when, and BOMs and ECOs export cleanly so your QMS record can reference or attach exactly what was approved. See how change orders work for the full workflow.
What it doesn't do is replace your QMS. oroForge doesn't provide Part 11 electronic signatures, so the signed approval of record belongs in your quality system, with the oroForge ECO number on it. That's the honest division of labor: the QMS proves the change was evaluated and approved; oroForge proves exactly what the change was.
It's free to start, and pricing for a full team is published, not quoted.
