One device, a small team, no regulatory department. The technical file looks like a mountain of documents — but most of it is records you'll produce anyway, if you produce them in the right order. Here's the sequence that works, what must start on day one, and what can wait.
First-time manufacturers picture the technical file as a writing project that happens near the end. That picture is what costs teams their launch quarter. Nearly everything Annex II asks for — requirements, risk analysis, design information, verification results — is a record of decisions you make during development. Make the records as you decide, and the file assembles itself; decide first and document later, and you're paying twice for everything.
One paragraph: what the device does, for whom, in what context. Every word becomes something to evidence — the claims, the clinical evaluation, the risk file all hang off it. Then classify against MDR Annex VIII with a documented rationale. Software teams: under Rule 11, software informing diagnostic or therapeutic decisions is at least Class IIa — Class I software is the exception. The class decides whether a notified body reviews your file, your timeline and your budget; settle it before you build.
IDs, versions, an approval rule, a place where the current version of anything is unambiguous. It feels bureaucratic with five documents; it's survival with five hundred. Every later artifact — requirements, risk entries, test reports — cites these IDs for a decade, so this is the one piece of infrastructure that cannot be retrofitted painlessly.
User needs in user language; system requirements as their measurable restatement; software/hardware requirements below. The levels are what make validation and verification provable later. Resist writing implementation notes as requirements — the 800-row flat list is the classic first-timer trap.
Hazard → hazardous situation → harm, per ISO 14971, starting from your earliest architecture sketches. Risk controls become requirements with a second parent, and the risk file keeps evolving with every design decision. A risk analysis written after the design is finished reads exactly like what it is — and reviewers have seen thousands of them.
For software, that's IEC 62304: a plan, a safety class with rationale, traced requirements, controlled SOUP, verification at every level. Most healthy engineering teams already behave this way — the gap is the controlled record, and it's much cheaper to keep as you go than to reconstruct from git history.
Open the GSPR checklist early and fill it as evidence appears. Used this way it's a to-do list that tells you which testing and documentation you still owe while you can still plan for it. Used at the end, it can only report the gaps you no longer have time to close.
The clinical evaluation (Article 61, Annex XIV) takes calendar time — literature work, possibly data collection — so its plan belongs in the middle of the project, not the end. The PMS plan (Annex III) is mandatory for every class and is mostly process description: cheap to write early, painful to fake later.
If steps 1–7 produced controlled records, assembly is exactly that: the device description chapter, the labeling set, the V&V summaries, the GSPR matrix export, each citing records at named versions. Then the Declaration of Conformity — the document where you, not your notified body, assert that everything above is true.
The useful triage rule: anything that is a record of a decision or a result — intended purpose, requirement rows, risk entries, test results, SOUP inventory — must be captured when it happens, under control. Anything that is a narrative view over records — the formatted device description, the executive summaries, the final matrix exports — can be produced late and cheaply, provided the records exist.
This is also the honest answer to "do we need a QMS tool from day one?" You need the discipline (IDs, versions, links) from day one. Whether a spreadsheet carries that discipline for your first year is a question of change volume — see the traceability guide for the symptoms that tell you it no longer does.
Regulation (EU) 2017/745 (MDR), consolidated text — Annex VIII (classification), Annexes II & III (technical documentation), Article 61 (clinical evaluation).
MDCG guidance documents — in particular MDCG 2019-11 on the qualification and classification of software.
Threeqa gives a one-product team the structure from step one: controlled requirements, a living risk file, traced evidence — so the technical file is assembled continuously, not excavated at the end. Book a 30-minute walkthrough.