In the first part of this series, we looked at the early decisions that shape a medical device project: intended use, requirements, risk management, regulatory strategy, and clear responsibilities.
Once the direction is set, the next challenge is building the structure that supports development.
For startups, this is often where the balance can feel difficult. A quality management system may sound like something that belongs closer to certification. Technical documentation may feel like something to assemble once the product is more mature.
In practice, leaving these elements too late often creates more work, not less.
A QMS and technical file should not be built after development. They should grow with the product.
A QMS is a structure for development
An ISO 13485 quality management system is sometimes viewed mainly as a certification requirement.
That view is too narrow.
A functioning QMS gives structure to the way the company works. It defines how decisions are documented, how changes are controlled, how responsibilities are assigned, how suppliers are managed, how risks are handled, and how development activities are reviewed.
For startups, this structure does not need to be unnecessarily heavy. The system should be proportionate to the company, the device, and the development stage. A small company developing a relatively straightforward device does not need the same operational complexity as a large manufacturer with multiple products and sites.
But the core processes need to exist, and they need to be used.
A QMS should function as a management system that guides both the company and the development project. If it only exists on paper, it provides little practical value. It must be part of how work is actually done, with appropriate records to show that processes are being followed.
Technical documentation should not be reconstructed later
A technical file is much harder to build retrospectively than many teams expect.
If development decisions, design reviews, test plans, risk management activities, and verification results are not documented as they happen, the team may later need to reconstruct the project from scattered notes, old files, or memory. That is rarely efficient, and in some cases it may not be possible to do reliably.
This is one of the most common sources of avoidable rework.
Technical documentation should grow alongside development. As requirements are defined, they should connect to risks. As design decisions are made, they should be reviewed and recorded. As verification and validation activities are planned, the rationale, methods, and results should be documented in a way that supports regulatory review.
This does not mean the technical file must be complete on day one. It means the framework should be in place early enough that development generates usable documentation as it progresses.
Clinical evaluation and evidence planning need early attention
Clinical evaluation is another area that should not be left until the end.
The clinical evidence needed for a device depends on the intended use, claims, classification, and available data. If these elements are not considered early, companies may make incorrect assumptions about what evidence will be sufficient.
This can become costly.
If a clinical study is planned with the wrong endpoints, or if it does not support the intended clinical claims, the resulting data may not be useful for the technical documentation. In the worst case, a company may need to repeat major parts of the work.
Clinical evaluation and clinical evidence planning should begin as early as possible because they are an essential part of device development. Wrong assumptions about clinical data can lead to significant delays, unnecessary costs, or evidence that does not support the intended claims.
Testing should follow a controlled process
Testing is not only about generating results. It is also about showing that the right tests were planned, performed, documented, and connected to the right requirements.
This applies to verification, validation, usability, safety, performance, and device-specific testing. The details vary depending on the device, but the principle remains the same: testing should be planned within a controlled development process.
When testing is performed informally or without proper documentation, the results may be difficult to use later. Teams may know that testing was done, but lack the records needed to demonstrate how it was planned, what acceptance criteria were used, what version of the product was tested, and how the results support the device claims.
Late documentation work can then become a repair exercise. In some cases, tests may need to be repeated simply because the original work was not structured or recorded in a way that supports compliance.
Late QA/RA involvement creates avoidable rework
When quality and regulatory input is introduced too late, problems often appear in places that seemed practical at the time.
A component may not be suitable for medical device use. A material choice may create biocompatibility concerns. In-house testing may lack appropriate plans and reports. Supplier selection may not meet the required expectations. The development team may have made reasonable technical decisions without recognising their regulatory implications.
These issues are not always dramatic at the moment they occur. But they can become significant later, especially when the technical documentation is being prepared for review.
This is why early QA/RA involvement is so important. It helps ensure that development decisions are made with awareness of the requirements they need to support.
The goal is not to slow development. The goal is to reduce the amount of corrective work needed later.
Build enough structure to move faster later
For startups, the right approach is not to overbuild the system too early.
A QMS should be proportionate. Documentation should be practical. Processes should support the team’s actual work. But there needs to be enough structure to ensure that development, testing, documentation, and regulatory planning remain connected.
This is where experienced support can be valuable. Startups do not need to build everything alone, but they do need to understand where their own expertise ends and where external support is needed. Companies can often save time and cost by bringing in the right expertise early, rather than trying to learn and build everything internally from scratch.
A good system should make the project easier to manage. It should clarify what needs to happen, what has already been done, what evidence exists, and what gaps remain.
From development to CE readiness
A smoother CE path is rarely the result of last-minute documentation work.
It is usually the result of clear processes, realistic planning, and continuous alignment between product development, quality management, regulatory strategy, testing, and clinical evidence.
For startups and companies developing new devices, the practical lesson is clear: build the system as the product develops.
That does not mean making the project heavier than necessary. It means creating enough structure early so that the work done during development can support the technical file, the QMS, and the eventual CE marking process.
When documentation, testing, and regulatory planning grow with the product, the path forward becomes more manageable.
If your team is building a medical device and preparing for ISO 13485, MDR technical documentation, or CE marking, MDS supports companies with practical quality and regulatory expertise across the development process.
You can contact us at Kristian@mdsdenmark.dk or via Book a Meeting.