By Kandih Bioscience · Design Controls & Biocompatibility Series · 2026
“We have Jira, Google Drive, and a Notion doc nobody updates. FDA just asked for our design history file. I have no idea where anything is.”
— r/medicaldevices, 180 replies
That post hit home because it is honest. And it describes a situation that is far more common than anyone in the medical device industry admits aloud.
The tool is never a problem. The missing system behind the tool is.
A Jira board is not a design history file. A Google Drive folder is not documenting control. A Notion doc three people stopped updating is not a living design record — it is a frozen snapshot of what someone understood six months ago.
In 2026, the r/medical devices thread asking which PLM tool is right for a small team is one of the most active recurring conversations in the community. The tools have improved. The confusion about using them correctly for FDA compliance has not.
What FDA Is Actually Looking For
Before tools, be precise about what a design history file has to contain. Under 21 CFR Part 820.30, it must demonstrate that your device was built under a controlled process. That means:
- Design inputs — the requirements the device had to meet before anyone built anything.
- Design outputs — the specs, drawings, and configurations that define what was built.
- Verification records — proof that outputs meet inputs.
- Validation records — proof that the device works for its intended user in real conditions.
- Change history — every design changes, why it was made, and whether it triggered re-testing.
FDA reviewers do not care which software you use. They care whether the records are complete, traceable, and retrievable on demand. A beautiful folder structure with broken traceability is still a DHF gap.
What Reddit Actually Recommends — and Why the Advice Varies
Recommendations cluster into three categories. Which one fits depends on where you are in development.
Purpose-built quality management systems.
Tools like Greenlight Guru, Dot Compliance, and Veeva Vault are built specifically for FDA-regulated device manufacturers. Design control modules, document workflows, change order processes, and audit trails are built in. They cost more. They are also the closest to plug-and-play for teams that need to be inspection-ready quickly.
Reddit consensus for teams within 18 months of a first submission: if you can afford one, start there. The time you save by not rebuilding your documentation later is worth more than the subscription.
Configurable platforms.
Tools like Arena PLM, PTC Windchill, and Propel are designed for regulated product companies and can be configured for medical device design controls. They need someone with regulatory knowledge to set up the workflows correctly, but they scale well for complex products or multiple device lines.
General tools configured carefully.
Jira, Confluence, Notion — these can work for early-stage teams with limited budgets. The Reddit post at the top of this page is what happens when they are used without the configuration and discipline they require. The tool is capable. The structure behind it was never built.
The right PLM tool for a three-person startup is not the right tool for a 30-person team. But the documentation standard FDA applies to both is identical. Your tool choice needs to reflect that — not just your current headcount.
Where Biocompatibility Fits In — and Why Most Teams Miss It
Design controls and biocompatibility look like two separate workstreams. They are not.
Your biological evaluation plan, chemical characterization data, ISO 10993 test reports, and biological evaluation report are all part of your design history file. Material selection decisions need to be documented as design outputs, traceable to device requirements that include biological safety criteria. Biocompatibility test records need to reference the specific device version and material lot they apply to.
Most small teams build their DHF with no connection between the materials section and their biocompatibility testing documentation. FDA finds that gap. Acquisition due-diligence teams find that gap. Closing it after the fact takes far longer than building the connection correctly from the start.
If your material supplier changed a formulation since your last biocompatibility testing — even quietly, without telling you — and that change did not flow through your change control process, your original biocompatibility data may no longer cover the device you are submitting.
Where Kandih Bioscience Comes In
The PLM question and the biocompatibility question are the same problem: a documentation system that does not connect design decisions to safety evidence in a way FDA can follow.
We help device teams close that gap; reviewing your current documentation structure, identifying where biocompatibility records are disconnected from your design history file, and building a biological evaluation strategy that integrates cleanly with your existing workflow.
If you recognized your team in that Reddit post, this is the conversation to have before the inspection — not after. If you are an investor trying to understand whether a company’s documentation is inspection-ready or a risk you have not priced yet, we can give you a plain-language answer.
Visit Our Biocompatibility Service Page
Schedule directly:
Book a Biocompatibility Review
or email connect@kandih.com · call 240.565.8933 · kandih.com
References
1. FDA — Design Controls Guidance for Medical Device Manufacturers (21 CFR 820.30) (1997, updated 2023)
2. FDA — Quality System Regulation: 21 CFR Part 820 (current)
3. FDA — Use of International Standard ISO 10993-1: Biological Evaluation of Medical Devices (2020)
4. ISO 13485:2016 — Medical Devices: Quality Management Systems (2016)
5. FDA — Design History File and Device Master Record Checklist (2014)
6. FDA — eSTAR 510(k) Submission Template and Guidance (2023)