Building technical documentation from day one does not mean producing an Annex II-ready technical file from day one. It means keeping a disciplined rationale trail from the first feasibility experiment, structured in a way that can be migrated into Annex II format after design freeze. The goal is traceability, not compliance theatre. Startups that confuse the two either drown in paperwork for a product that keeps changing, or arrive at their first audit with nothing but hope and a GitHub history.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • "Day one" technical documentation is a rationale trail, not a formatted Annex II technical file. The format comes later. The content has to exist from the start.
  • MDR Article 10(4) of Regulation (EU) 2017/745 requires manufacturers to draw up and keep up to date technical documentation in accordance with Annex II and Annex III — but this obligation attaches to the device intended to be placed on the market, not to every early prototype.
  • In Phase 1, the goal is disciplined lab notebooks, decision logs, and rationale records. In Phase 2, those records get migrated into Annex II structure under formal document control aligned with EN ISO 13485:2016 + A11:2021.
  • The design-freeze moment is the trigger to switch formats. Before it, you keep notes. After it, you run a document control system.
  • We have seen a 3-person Lower Austria startup pass its first Notified Body audit with zero nonconformities on technical documentation by following this discipline. We have also seen a well-resourced Graz company go paralytic by trying to produce Annex II-format documentation from day one.

Why "day one" is a loaded phrase

There is a Graz-based company we know well that set out on day one to document everything to full MDR compliance. Every bench experiment logged in a controlled document. Every prototype iteration versioned in a formal design history. Every internal discussion captured in a templated meeting minute. They wanted to be "audit-ready from day zero" — the phrase every regulatory conference loves.

The result was a development slowdown of roughly 90 percent. A product that could have been on the market in 2020 is still not on the market in 2026. Six years of bureaucratic friction on a device whose fundamental design changed five times during that period. Most of the documentation they produced described products that no longer exist.

That story is the cautionary anchor for this post, and it is also why the phrase "technical documentation from day one" is dangerous in startup contexts. Read literally, it tells founders to produce Annex II-format records before they know what the device actually is. That is not discipline. It is paralysis in the costume of compliance.

The right reading is different. From day one, you should be capturing the information that will eventually feed your technical file. What you should not be doing is pre-formatting that information into the shape of a Notified Body submission for a device whose architecture will change ten more times.

This post connects directly to the two-phase development approach. If you have not read that one, read it first. Everything here is the technical-documentation application of the same underlying discipline.

What MDR Article 10 actually requires

MDR Article 10 sets out the general obligations of manufacturers under Regulation (EU) 2017/745. Two provisions matter most for technical documentation.

"Manufacturers of devices other than custom-made devices shall draw up and keep up to date technical documentation for those devices. The technical documentation shall be such as to allow the conformity of the device with the requirements of this Regulation to be assessed. The technical documentation shall include the elements set out in Annexes II and III." — Regulation (EU) 2017/745, Article 10, paragraph 4.

And the QMS obligation:

"Manufacturers of devices other than investigational devices shall establish, document, implement, maintain, keep up to date and continually improve a quality management system..." — Regulation (EU) 2017/745, Article 10, paragraph 9.

Two observations matter for startups. First, Article 10(4) talks about "devices" — meaning the specific device being placed on the market, not every experimental artifact produced on the way there. Second, Article 10(9) explicitly excludes investigational devices from the full QMS obligation. The Regulation already knows the difference between research activity and market-ready manufacturing.

Annex II of the MDR specifies the structure of the technical documentation: device description and specification, information to be supplied by the manufacturer, design and manufacturing information, general safety and performance requirements, benefit-risk analysis and risk management, product verification and validation. Annex III specifies the post-market surveillance technical documentation — the PMS plan, PMSR or PSUR, and the underlying PMS system outputs.

Nothing in either Annex requires you to produce documentation in final Annex II format for a prototype that will never be placed on the market in that form. What the Annexes do require is that, by the time you submit to a Notified Body, every element they list is present, coherent, current, and traceable.

The question for a startup is not "how do I produce Annex II from day one" but "how do I capture the information now so that producing Annex II later is a migration job, not an archaeology dig."

What to record in Phase 1

Phase 1 is feasibility. You are answering questions: does the technology work, does the clinical concept hold, can the device be built at a reasonable cost, is the user flow sensible. You do not yet know exactly what you are building, so you cannot yet format documentation around a stable design.

What you should record in Phase 1:

  • Lab notebooks. Real ones. Dated, sequential, not retroactively edited. Every bench experiment, every measurement, every anomaly, every hypothesis, every failed attempt. Paper notebooks are fine. Electronic lab notebooks are fine if they have proper audit trails. The format matters less than the discipline of actually keeping them.
  • Decision logs. Every major technical or strategic decision, the options considered, the reasoning for the choice, the date, and who made it. When you eventually write the design rationale section of your technical file, this log is gold. Without it, you will be reconstructing reasoning from memory under audit pressure, which is the worst possible time.
  • Intended purpose drafts. Even if the intended purpose is unstable, write it down. When it changes, write the new version down with the date and the reason for the change. The evolution of the intended purpose tells you something important about the device's maturity.
  • User and clinical observations. Notes from clinician interviews, workflow observations, user feedback. These become input to your eventual usability engineering file and clinical evaluation.
  • Early risk thinking. Not a formal ISO 14971 risk management file yet. A running list of the hazards you are worried about and your current thinking on how to control them. This becomes the seed of your formal risk file in Phase 2.
  • Key correspondence. Emails with potential Notified Bodies, early conversations with clinical partners, any regulatory agency contact. Keep them findable.

What you should not do in Phase 1 is format any of this in Annex II structure. You do not yet have the stable design that Annex II is organized around. Imposing the structure too early forces you to invent section content that does not exist yet, which leads to fiction in compliance documents — the worst failure mode.

The design-freeze moment

The switch from Phase 1 discipline to Phase 2 discipline happens at design freeze. This is the single most important moment in the technical documentation timeline, and it is a decision, not a gradient.

A competent design freeze means several things happen together. The intended purpose is stable enough to write in a single paragraph that stops changing. The classification is understood with confidence. The device architecture is settled — the components, the software modules, the interfaces, the materials. The major risks are identified and you have at least a conceptual approach to each one. The conformity assessment route is known.

Before design freeze, the documentation goal is: capture everything that will be needed later, fast, without formatting overhead. After design freeze, the goal changes: formal document control, version management under EN ISO 13485:2016 + A11:2021, every change tracked, every approval recorded, every revision traceable.

This is the moment when the rationale trail from Phase 1 gets migrated into the shape of Annex II. It is not a full rewrite — the content already exists. It is a restructuring and formalization job.

What to migrate to Annex II format in Phase 2

When you cross the design-freeze line, the Phase 1 material gets reorganized into the Annex II structure. The mapping is not mysterious:

  • Lab notebook material feeds the design and manufacturing information, the verification and validation records, and parts of the risk management file.
  • Decision logs feed the design rationale sections and the risk control justifications.
  • Intended purpose drafts collapse into the final intended purpose statement in the device description — with the version history of the drafts becoming part of your design history if an auditor ever asks how the intended purpose evolved.
  • User and clinical observations feed the usability engineering file, the clinical evaluation plan, and the early sections of the clinical evaluation report.
  • Early risk thinking becomes the seed for the formal risk management file built per the standard.
  • Correspondence becomes part of the quality records under the QMS.

The migration is a controlled, intentional act. It takes weeks, not months, if the Phase 1 records were kept properly. It takes many months — sometimes never finishes — if Phase 1 was a mess.

For more on how this structure looks once it is formalized, see our posts on technical documentation under MDR, MDR Annex II structure, and MDR Annex III PMS technical documentation.

Structure-first thinking, without structure-first formatting

There is a useful middle position between "format everything to Annex II on day one" and "capture everything in whatever format you feel like." That position is structure-first thinking.

Structure-first thinking means: from day one, you know what Annex II looks like. You know the rough shape of the technical file you will eventually produce. You keep that mental model in mind while you work, so that the notes you take, the decisions you log, and the experiments you run all generate material that will eventually land somewhere in the Annex II skeleton.

You are not pre-filling the skeleton. You are just aware of where things will go, so you do not accidentally throw away the kind of evidence the skeleton will later demand. The difference between a founder who has read Annex II and a founder who has not is visible in their lab notebooks — one of them captures design rationale naturally, the other has to reconstruct it later.

The minimum viable tool for structure-first thinking is a one-page Annex II outline pinned above the bench. You do not need a document management system yet. You need the map.

The 3-person company that outperformed larger teams

Against the Graz cautionary tale, there is a Lower Austria company we worked with — three people, one device, narrow intended purpose, tight runway. They did not try to run an Annex II-format documentation system in Phase 1. They ran lab notebooks and decision logs, kept their intended purpose drafts version-dated, and captured their early risk thinking in a single running document.

When they hit design freeze, they migrated that material into Annex II structure over about six weeks, following Annex II section by section, filling each section from the Phase 1 material that was already there. Their first Notified Body audit came in with zero nonconformities on technical documentation. Three people. One device. Discipline in the right order.

The Salzburg SaaS startup from our two-phase development post is another variant of the same story. They used Phase 1 to validate algorithms on retrospective hospital data — no MDR documentation machinery, just proper scientific record-keeping — and only moved to Phase 2 technical documentation once they knew the algorithms actually worked. The move into Annex II format was clean because the rationale trail was already there.

The pattern across both companies is the same. Record from day one. Format when the design is stable.

Common mistakes startups make with early tech docs

  • Over-documenting too early. Trying to produce Annex II-format records in Phase 1, which forces you to invent structure around a moving target. This is the Graz pattern. It looks diligent. It is paralysis.
  • Under-documenting the rationale trail. Building fast without keeping lab notebooks or decision logs, on the theory that "we will write the documentation at the end." At the end, the reasoning is gone. You will be reconstructing design rationale from memory, badly.
  • Treating the QMS as the documentation system during Phase 1. The QMS is a Phase 2 tool. In Phase 1, you need notebooks and logs, not a controlled document library full of draft SOPs that will be rewritten anyway.
  • Forgetting that the intended purpose history matters. If your intended purpose changed five times, an auditor may ask why. Keeping the drafts dated and annotated saves you from an awkward conversation.
  • Assuming design freeze is obvious. It is not. Startups drift past design freeze without noticing, then realize three months later that they have been iterating when they should have been documenting. Name the moment explicitly, on a date, in writing.
  • Skipping document control after design freeze. The other failure mode: crossing design freeze but continuing to work out of shared drives and ad-hoc folders. After design freeze, you need version control discipline per EN ISO 13485:2016 + A11:2021. See our post on document control and version control under MDR.

The Subtract to Ship angle

The Subtract to Ship framework for MDR says: do only what the regulation actually requires for your specific device, and cut everything else. Applied to technical documentation, it means two separate subtractions at two separate moments.

In Phase 1, subtract every documentation activity that is not capturing rationale, decisions, or experimental evidence. No Annex II-format templates. No QMS theatre. No compliance-flavoured paperwork that will be rewritten anyway. Keep the notebook. Log the decisions. Write down the intended purpose. That is it.

In Phase 2, subtract every Annex II section that does not apply to your specific device. Annex II is a menu, not a shopping list. A software-only device does not need biocompatibility. A non-implantable device does not need everything implantables need. An IIa device does not need the full Class III clinical evidence depth. Build only what the conformity assessment for your actual device requires.

The discipline is the same in both phases: keep what matters, cut what does not, never confuse activity with progress. The danger is applying the discipline in only one of the two phases — either over-documenting in Phase 1 and then being slow in Phase 2, or under-documenting in Phase 1 and then being panicked in Phase 2.

Reality Check — Where do you stand?

  1. Can you produce, within 24 hours, a dated rationale for the three biggest design decisions you have made in the last six months? If not, you are under-documenting the rationale trail.
  2. How many of your current prototype records are in a format you will throw away when you migrate to Annex II? If the answer is "most of them," you may be over-formatting too early.
  3. Do you have a one-page Annex II outline pinned somewhere visible on the team? If not, you are not doing structure-first thinking.
  4. Have you named a specific person on your team who will make the design freeze call, and do they know the criteria for calling it? If not, freeze will either happen too early or never.
  5. If a Notified Body auditor asked tomorrow to see the evolution of your intended purpose, could you produce dated drafts? If not, that is a gap you can close this afternoon.
  6. Of the technical documentation work you did last month, what percentage described the current version of the device and what percentage described a version that no longer exists?
  7. When you cross design freeze, do you have a clear plan for migrating Phase 1 records into Annex II structure — or will it be an unplanned scramble?

Frequently Asked Questions

Does "from day one" mean I need a QMS on day one? No. MDR Article 10(9) of Regulation (EU) 2017/745 explicitly excludes investigational devices from the full QMS obligation. In Phase 1, you need disciplined records, not a formal quality management system. The QMS comes when you cross design freeze into Phase 2, and it is built per EN ISO 13485:2016 + A11:2021.

How do I know when to stop using lab notebooks and start using controlled documents? The transition happens at design freeze. Before freeze: lab notebooks, decision logs, running risk notes, dated intended purpose drafts. After freeze: formal document control, version management, change control, the full QMS machinery. The moment itself is a decision you name explicitly, on a date, in writing.

What if my design never fully freezes? Then you are stuck in Phase 1 forever, and you will never certify. A device that cannot be pinned down enough to document cannot be pinned down enough to put on the market safely. If you cannot freeze a design, that is a signal you are still doing feasibility research — which is fine, but it means you are nowhere near a technical file yet.

Can I use project management tools like Notion or Jira as Phase 1 documentation? Yes, if they give you dated, versioned, reliable records. The test is whether you can reconstruct, months later, the exact state of a decision on a specific date. Tools that let you retroactively edit history without audit trails are risky. Tools with proper version history work fine for Phase 1 purposes.

What is the minimum technical documentation I should have before my first Notified Body conversation? For a pre-audit introductory conversation, a Notified Body typically expects a stable intended purpose, a classification rationale, a device description at a reasonable level of detail, and evidence that you understand the conformity assessment route. They are not expecting a complete Annex II file. For the actual audit, see our post on how to prepare for your first Notified Body audit.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers), in particular Article 10(4) (technical documentation) and Article 10(9) (quality management system), Annex II (technical documentation), Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. The harmonised standard governing document control, version management, and change control in the MDR QMS.

This post is part of the Technical Documentation and Labeling series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. If you are approaching design freeze and unsure whether your Phase 1 records will actually migrate cleanly into Annex II structure, Zechmeister Strategic Solutions runs structured pre-freeze reviews for founders who want an outside read before the formal documentation machinery kicks in.