A few weeks ago I was at MedTech Innovator in Manhattan Beach, and I watched a company present a device that sits on the outside of the body, stimulates the vagus nerve through the branch that runs to the spleen, and modulates the immune system. Without drugs and without surgery, just an external neurostimulator quietly rewriting how some of us think about inflammation.
A few tables down, researchers were working on regenerative therapies inspired by the axolotl, that salamander that regrows limbs, pieces of its heart, parts of its spinal cord. Not because they love salamanders, but because they believe that within our lifetimes, possibly within years, we are going to help humans heal tissue in ways that today sound like science fiction.
I'm not here to promote those specific companies, but both of those devices depend on software. And every software product behind them is going to need a quality system. And every single one of those quality systems, as they exist today in most companies, is fighting against the way those teams actually work.
That's the problem I want to talk about.
The parallel worlds problem
If you work in quality or regulatory, there's a reasonable chance you started this morning thinking about a deviation, or an audit finding, or a document that needs to be routed for signature. That's real work, and it matters. The reason it matters, the reason most of us are in this industry, is because of those tables at MedTech Innovator. The neurostimulators. The regenerative therapies. The continuous glucose monitors that have already changed what type one diabetes looks like for millions of people.
Before I describe the problem, think about that. The devices are the point, not the binders, not the SOPs, not the records. The devices, and the patients waiting for them.
Here's what I've come to believe after several hundred conversations with med tech founders, quality leaders, regulatory professionals, and engineers on the podcast and at live events: your engineers live in one world, and your compliance lives in another. Your quality team spends most of its working hours translating between them.
Picture a software engineer on a software-enabled medical device team. Where are they working? They're in GitHub, where the code lives, where pull requests get reviewed, where every decision is recorded. They're in Jira, where user stories get defined, bugs get triaged, and the team decides what ships this sprint. They're in their CI pipeline, their Slack channels, their code review tools. Those are the systems where the real work of building the product actually happens.
Now picture where the compliance records live. They live somewhere else entirely: a separate eQMS with a different login, a different information architecture, and a different vocabulary. Design outputs instead of pull requests, change record instead of a commit, verification protocol instead of a test run. Everything the engineer already did, already documented, already linked and reviewed, has to be redescribed in a different system, in a different language, by someone who frequently was not there when the original decision was made.
Every pain point our industry complains about is downstream of that divide.
Why the drift happens
When engineers defer compliance work, the reason is not carelessness but a rational response to the tool mismatch. Doing it in the moment would mean leaving their tools, switching context, opening a different system, and redescribing work they already finished in a language that system demands. Ask any engineer on any team anywhere to do that forty times a week and they will say they will catch up on it later.
Later becomes never. Never becomes the week before submission, when three engineers get pulled off the product for a month to reconstruct a paper trail of work they did six months ago.
The reconstruction sprint is where most of the cost of software compliance actually sits, not in the regulations and not in the reviewers. It sits in that translation layer: the weeks of engineering time, the months of QA time, the late nights before an audit, all of it spent converting work that happened in one system into a record that lives in another.
Here's what makes it worse. The longer those two worlds stay separate, the more they drift. A change gets made in GitHub. It does not make it into the eQMS that week. Next month, there is a new change built on top of the first, and now the compliance record reflects a version of the product that might not exist anymore. Multiply that by a year of development, and by the time you are preparing to submit to the FDA or any other regulatory body, your eQMS might tell the story of a product that lives in an alternate universe where no one ever fixed a bug.
A misalignment doesn't have to be large to matter. A flight path off by a single degree will miss its destination by hundreds of miles. The same principle applies here.
None of this is a moral failing, and none of it is a training problem. You cannot train or discipline your way out of a tool mismatch. You can hire the best QA team in the industry and write the most elegant SOPs ever filed, and as long as the development system and the compliance system are in two separate worlds, someone is going to be translating between them. That translation layer is where your speed, your money, and your sanity go.
Why the story held for so long
The incentives protected the old way. Nobody got promoted for being bold in quality; the promotions went to the careful ones. Nobody got fired for keeping the legacy eQMS. And the industry told itself a story: that regulators would not accept modern tools, that you had to keep those parallel worlds because compliance required it.
The story is no longer true.
QMSR, the Quality Management System Regulation that aligned US requirements with ISO 13485, shifted the FDA's emphasis from "do you have the record" toward "does your system actually work." That is not a reshuffling of the deck. It is a signal of where the agency is going: alignment with modern tools and a modern way of thinking about quality.
Predetermined change control plans (PCCP), introduced through the Omnibus Act in December 2023, were not written for artificial intelligence and machine learning alone. They were written for medical devices in general. What the FDA was saying in plain language was: we know your devices change, so bring us a plan for how you will manage those changes, not a frozen snapshot of where you are today.
IEC 62304 reviewers now understand software development in ways that would have been unthinkable a decade ago. The standard has evolved to meet the reality of how software is actually built.
The regulators moved, the technology moved, and the patients have been waiting. The only thing that has not moved is the tooling most companies are still running on, which is actually good news, because it means the thing holding us back is the one thing we can actually change.
What compliance looks like when it works
The shift I'm describing is captured in a single sentence: compliance is a property of how the product is built, not a tax paid after the fact.
Change records that aren't written after the change but that are the change. The pull request in GitHub is the design change record. The Jira ticket is the user need, traced to the requirement, traced to the verification. The commit is linked to the risk control it implements, not because someone went and wrote it down in a second system three weeks later, but because the compliance record was captured automatically in the system where the actual work was already happening.
A risk file that's not a quarterly activity you dread but a live picture of the product. Every decision that affects risk updates in the moment it is made. Your risk analysis stops being a snapshot of what you thought six months ago and starts being an accurate reflection of what your product is right now. If you have ever felt like your risk file and your actual product drifted apart, you already know the cost of that drift.
A submission that doesn't require a three-month reconstruction sprint because nothing was ever lost. You were not re-engineering the design history file based on the engineer's memory. Your auditors find a clean, continuous record that tells a coherent story from the first sprint to the last design review.
None of this is hypothetical. Teams working this way already exist. The connection between application lifecycle management (ALM) tools like Jira and GitHub and design controls is an established pattern, not a future state. The companies doing it well are seeing the difference in their audit timelines, their submission prep, and the relationship between their engineering and quality teams.
The engineer stays in their stack
The practical version of this future is straightforward. The engineer never leaves their tools. The compliance record becomes a byproduct of the development work rather than a second layer on top of it. The quality professional stops spending their time as a translator between two systems and starts spending it on the work that actually requires quality judgment: the risk calls, the clinically significant calls, the reviewer conversations, the post-market signal analysis.
Quality people still need to interface with regulators and speak that language. That part does not go away. But the work of generating and maintaining the underlying records, which today consumes enormous amounts of human time, starts to happen as a function of how the software is built.
Engineers work where they work, the quality team works where they work, and the systems connect the two.
AI is accelerating the shift
Something else is making this move faster, and I think we still underestimate it. The grunt work of quality, the documentation comparison, the traceability mapping, the gap analysis, the first-draft procedures, the triage question of whether a change requires a corrective and preventive action (CAPA), is starting to be automated. Not replaced. Automated.
When that happens, the humans in quality and regulatory get to focus on the parts of the job that actually require a human: the judgment, the context, the ethics, the clinical reasoning, the conversation with reviewers. Your job is not going away. It is becoming more interesting than it has ever been. You are about to spend less time as a document librarian and more time as the person who decides whether a device is actually safe and effective.
As an ISO 13485 lead auditor, I've spent years with the standards. But what I actually signed up for, what I think most people in quality and regulatory signed up for, was the judgment work: deciding whether a device is sound, whether a patient gets access to it this year or five years from now. The documentation work was always just the path to that. As the grunt work gets automated, the judgment work becomes the job.
The decision that compounds
For companies that are pre-market right now, building a first quality system and choosing what they will run on for the next five years: that decision compounds. The infrastructure you choose in the next six months will shape how fast you ship, how clean your audits are, and how much of your runway goes to the product versus the paperwork.
The goal is to find the system that matches how your team actually works, so that compliance and development stay in step from the first sprint rather than diverging and requiring reconstruction at the end.
Greenlight Guru Ultralight was built for software-enabled device teams who need compliance to live inside the development workflow rather than alongside it. But whatever system you choose, the principle is the same. The parallel worlds can collapse into one. The companies building with that model today are the ones building the next generation of devices that will matter to patients.
Here's the thing nobody tells you at the beginning of a quality career. An engineer builds one product. A quality leader builds the system that determines how fast every product the company will ever make reaches the people who need it. You're a multiplier. You always have been.
Choose the system that matches the medicine you are trying to make possible.
Keep reading
- Software as a medical device (SaMD): the ultimate guide
- IEC 62304: what software teams need to know
- ALM and design controls: connecting your development workflow to your quality system
- QMSR: your guide to the updated 21 CFR Part 820
- FDA guidance on AI-enabled devices and predetermined change control plans
Watch the on-demand recording: The software problem in medtech
BONUS RESOURCE:
3-in-1 SaMD Gap Assessment Tool
3-in-1 SaMD Gap Assessment Tool
