A Salzburg-based SaaS startup moved from the start of its compliant build to a Class IIa CE mark in twelve months. It worked because the founders had already spent a prior phase proving feasibility outside the MDR, wrote the intended purpose before opening an IDE on the compliant codebase, classified early under Annex VIII Rule 11, picked a Notified Body before writing the technical documentation, and refused to add a single document that did not trace back to a specific MDR obligation. This post walks the twelve months month by month, names the four decisions that made it work, and lists the mistakes the team avoided. The company is anonymised; the sequence is real.

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

TL;DR

  • A Salzburg-based SaMD startup reached Class IIa CE marking in twelve months of compliant build, after a prior feasibility phase outside the MDR.
  • The twelve-month clock started the day the founders committed to the medical intended purpose and ended the day the Notified Body issued the certificate.
  • The four decisions that made the timeline possible: a clean intended purpose written before code, early Rule 11 classification under Annex VIII, an early Notified Body choice, and a ruthless subtraction pass on every document and process.
  • The team avoided the classic time killers: template QMS bloat, late Notified Body selection, late clinical evaluation, scope creep, and rebuilding documentation after the fact.
  • Twelve months is not a universal promise. It is achievable for Class IIa SaMD with a clean intended purpose, disciplined founders, a Phase 1 behind them, and a Notified Body with realistic queue times.

The 12-month claim

Twelve months from kickoff to CE mark for a Class IIa SaMD sounds aggressive because most of the timelines founders hear are two to three times longer. They are not wrong. The typical SaMD timeline from "we think we might be a medical device" to certificate is eighteen to thirty-six months, and many teams never finish at all. What shortens the clock is not a trick, a template, or a faster Notified Body. What shortens the clock is that most of the work that blows up MDR timelines is work that should not have been done in the first place, or work that should have been done in a different order.

This post is a real case study from a Salzburg-based SaaS startup we worked with. The company is anonymised per the rules of this blog, and the numbers are presented at the level of precision that survives anonymisation. The product was a clinical decision-support SaMD, Class IIa under MDR Annex VIII Rule 11, built for hospital use. The team was small, the funding was tight, and the founders had been told by two earlier advisors that the regulatory path would take three years. It took one.

Month 0 — the decision to start the MDR clock

Before the twelve months started, the company had already run a Phase 1 that was outside the MDR. The software had been built as a research tool, used on hospital data under research agreements, with no diagnostic or therapeutic claims. That Phase 1 produced the one thing a regulatory project cannot function without: a demonstrated product-market fit signal. The hospitals that used the tool were asking to scale it across more sites, and the founders had the evidence that the product worked on real data.

The decision to start the MDR clock came when the founders sat down and wrote the intended purpose of the medical version of the product — the full sentence required by MDR Article 2(12), naming the medical condition, the patient population, the clinical users, the clinical context, the output, and the intended downstream clinical decision. This is Stage 0 of the SaMD regulatory path (see post 417), and it was done before any new code was written under the compliant track. The intended purpose is the sentence that every downstream stage of MDR compliance depends on, and the founders who end up with a clean timeline write it first.

Months 1 to 2 — qualification, classification, and Notified Body choice

Month 1 was a single afternoon of qualification work followed by the documented rationale. The team walked the software through the MDCG 2019-11 Rev.1 decision tree against MDR Article 2(1), confirmed it qualified as Medical Device Software, and wrote the qualification rationale as a standalone document that would later sit at the top of the technical file. No ambiguity, no "we might be a medical device, we might not." The answer was binary, written, and dated.

Classification under MDR Article 51 and Annex VIII Rule 11 followed in the same week. The software provided information used for diagnostic or therapeutic decisions about individual patients, which under Rule 11 is Class IIa at minimum. The team did not waste time arguing for Class I. They accepted the Class IIa result, signed the classification rationale, and moved on. This single act of acceptance is where most SaMD startups lose their first six months.

By the end of Month 2, the company had selected a Notified Body. Not started the application, selected the body. The selection was made on the basis of queue time, software competence, and the body's history with early-stage SaMD. This is the Story 12 move applied to software — picking a Notified Body with realistic capacity rather than a prestigious name with an eighteen-month queue. The informal conversation with the body began in Month 2, which meant the company had a slot reserved by the time the technical documentation was ready.

Months 3 to 6 — QMS, risk, and the start of the lifecycle build

Months 3 through 6 were the lifecycle build. The company set up EN ISO 13485:2016+A11:2021 as its quality management system from scratch — not from a template. The entire QMS fit in about forty controlled documents. Every procedure was written to reflect how the company actually worked, not how a template imagined a company working. This is the contrast between the two QMS stories in Tibor's interview corpus: the company that bought a template and was still at "0.1 percent complete" six months later, and the company that built forty documents in eight weeks and passed the audit clean.

Risk management ran under EN ISO 14971:2019+A11:2021 in parallel with the QMS build, not after it. The risk file was a living document from Month 3, maintained in the same repository as the code. Every change to the software produced a delta in the risk file before the pull request was merged. This single discipline — risk management as code, not as a Word document updated at audit time — is what later allowed the technical documentation to be assembled without reconstruction.

The software lifecycle ran under EN 62304:2006+A1:2015. The team already had the discipline from Phase 1 — the code had been written under lifecycle-compatible practices even when the formal standard did not apply. Month 3 to Month 6 was largely a matter of making the existing discipline explicit: requirements traceability, architectural documentation, verification plans, problem resolution records. The activities were real; the documentation of the activities was what had to be produced.

Months 7 to 9 — clinical evaluation and technical documentation

Clinical evaluation under MDR Article 61 started in Month 7 and ran to Month 9. The company did not run a new clinical investigation. The clinical evaluation was built on the Phase 1 hospital-pilot data, supplemented by literature review and post-market data from equivalent devices. The evaluation was not cheap, but it was bounded because the intended purpose was narrow and the patient population was specific. A broad intended purpose would have required a much larger evidence base.

The technical documentation was assembled against MDR Annex II in Month 8 and Month 9. Annex II is the authoritative table of contents for the technical file, and the team used it as the literal structure of the file — one section per Annex II point, one document per section, one trail from every claim to a specific piece of evidence. The file was not a treasure hunt. It was navigable, and a stranger could find any fact in it inside ten minutes. This is the "zero non-conformities" pattern from the Lower Austria three-person company story applied to software.

Months 10 to 12 — conformity assessment and the certificate

The Notified Body audit happened in Month 10. The application had been submitted at the end of Month 9, the Notified Body slot had been reserved since Month 2, and the queue time was two weeks. The audit was a full Class IIa conformity assessment — QMS audit, technical documentation review, and the specific software-related review against MDR Annex I Section 17 and EN 62304:2006+A1:2015.

The audit produced findings. Every real audit produces findings. The total was four — one major, three minor — all closable inside the usual response window. The major finding was closed in six weeks. The minor findings were closed in parallel. By the end of Month 12, the Notified Body issued the CE certificate. The company placed the CE-marked software on the market the following week.

Total elapsed time from the start of the MDR clock to the certificate: twelve months. Total elapsed time including the Phase 1 that preceded the MDR clock: closer to twenty-four months. The Phase 1 was not certification work, but it was the work that made the certification work possible.

The four decisions that made the timeline possible

Decision 1 — the intended purpose was written first, and it was narrow. A narrow intended purpose shortens every downstream stage. The clinical evaluation is bounded. The risk management is bounded. The technical documentation is bounded. A broad intended purpose, written to "keep options open," multiplies the work in every stage that follows. The team accepted a narrow initial indication and planned to extend it later — after the first certificate — rather than trying to certify a broad one.

Decision 2 — classification was accepted early and without argument. The Class IIa result under Rule 11 was not something the team tried to negotiate down. The qualification and classification rationales were written and signed inside the first two weeks of Month 1. The months that other startups lose arguing for Class I, this team did not lose because they did not argue.

Decision 3 — the Notified Body was chosen in Month 2, not Month 9. Selecting the Notified Body before the technical documentation is built is how the queue time disappears from the critical path. The team's Notified Body had capacity, software competence, and an established relationship with early-stage SaMD. The two-month informal conversation before the formal application meant the body already understood the device by the time the file landed on the reviewer's desk.

Decision 4 — every document had to justify itself. The team ran a subtraction pass on every artefact the QMS, the risk file, and the technical documentation were going to contain. If a document could not trace to a specific MDR article, annex, or harmonised standard clause, it did not get written. The result was a QMS in the low tens of documents and a technical file that was as small as Annex II allowed. This is the Subtract to Ship framework applied in the cleanest possible way — less work, more certification (see post 65).

What the team avoided

Template QMS bloat. The team did not buy a template QMS and try to trim it down. Trimming a bloated template is harder than building a small QMS from scratch, and the gaps between the template's assumptions and the company's reality are where findings hide.

Late Notified Body selection. The team did not wait until the technical file was done to pick a Notified Body. Late selection adds queue time to the critical path, and queue time is the hardest delay to compress once it is there.

Late clinical evaluation. The team did not leave the clinical evaluation for the end. Clinical evaluation in parallel with technical documentation, built on Phase 1 data, is how the last three months of the timeline did not collapse under a clinical evidence gap.

Scope creep in the intended purpose. The team did not extend the intended purpose during the project. Every suggestion to add a new indication, a new patient population, or a new clinical context was deferred to a post-certificate extension. Scope creep in the intended purpose is the single most reliable way to turn a twelve-month project into a thirty-six-month project.

Reconstruction of documentation. The team did not write the software under consumer-software assumptions and reconstruct the documentation later. Reconstruction is more expensive than building it in, and it is the clearest path to a failed audit.

What almost broke the timeline

Two things came close to breaking the timeline. Both are worth naming because they are the same things that break most timelines.

The first was a request from an early investor to broaden the intended purpose to include a second patient population. The request was reasonable from a commercial standpoint — a broader indication meant a bigger addressable market. It was also a timeline killer, because it would have required re-running the clinical evaluation and expanding the technical documentation in Month 7, exactly when the team could least afford it. The founders said no and committed to a post-certificate extension. The investor was not happy for a week. The timeline survived.

The second was a design change to the underlying data pipeline in Month 8. The change was small from an engineering perspective, but it touched the risk file, the software architecture documentation, the verification plans, and the intended purpose boundary. Because the risk file was living in the repository and the discipline was already in place, the change was absorbed without restarting any stage. In a team that managed risk in a document updated at audit time, the same change would have cost four to eight weeks. This is the Story 19 lesson — that "small" changes are not small — applied preventively rather than reactively.

Lessons for other founders

The twelve-month timeline is not a universal promise. It is what is possible for a Class IIa SaMD when the preconditions hold: a Phase 1 has already produced a product-market fit signal, the founders will write and defend a narrow intended purpose, the classification is accepted without argument, the Notified Body is chosen early, the QMS and lifecycle are built under discipline rather than from a template, and the team is willing to subtract rather than add. Change any of those preconditions and the clock gets longer.

The lessons that generalise:

  • Do Phase 1 outside the MDR. The teams that reach twelve months almost always have a Phase 1 behind them. The teams that try to start MDR compliance on Day 1 usually end up with a longer total clock, not a shorter one (see post 51 and post 52).
  • Write the intended purpose before code. Every stage after Stage 0 depends on the sentence you write in Stage 0. A bad sentence poisons every stage.
  • Pick the Notified Body early. Queue time is the hardest delay to compress. Early selection means the queue time happens in parallel with other work, not on top of it.
  • Subtract, do not add. A forty-document QMS that reflects reality beats a four-hundred-document QMS that does not. A technical file that a stranger can navigate beats a treasure hunt.
  • Accept classification results. Arguing for Class I when Rule 11 says Class IIa costs months and does not change the outcome.

The Subtract to Ship angle

This case study is the cleanest application of Subtract to Ship we have seen in a SaMD project. The framework did two things at once. It subtracted the premature work that makes MDR projects long — the template QMS, the over-broad intended purpose, the bloated technical documentation, the late clinical evaluation, the negotiation with Rule 11. And it kept the engineering discipline that makes MDR projects possible — the risk file in the repository, the lifecycle-compatible development practices from Phase 1, the narrow intended purpose defended against pressure, the Notified Body chosen before the file was built.

The twelve months were not short because the team worked faster than other teams. The twelve months were short because the team did not do the work that other teams do and then have to undo. That is the entire framework in one sentence. Post 65 covers Subtract to Ship as applied to MDR in full. Post 30 covers minimum viable regulatory strategy. Post 725 covers the complete MedTech startup playbook into which this case study fits.

Reality Check — Where do you stand against this timeline?

  1. Have you run a Phase 1 outside the MDR that produced a real product-market fit signal, or are you starting compliance before the product has been validated?
  2. Is your intended purpose written down in a single paragraph, narrow enough to be bounded, and defended against scope creep from investors and co-founders?
  3. Have you accepted your Annex VIII Rule 11 classification, or are you still arguing for a lower class?
  4. Have you shortlisted Notified Bodies by queue time and software competence, and opened informal conversations with at least one, before writing your technical documentation?
  5. Is your QMS built from your actual processes rather than from a template, and does every document in it trace to a specific MDR or EN ISO 13485:2016+A11:2021 obligation?
  6. Is your risk file under EN ISO 14971:2019+A11:2021 living in your engineering repository, updated on every change, rather than reconstructed at audit time?
  7. Are your software lifecycle activities under EN 62304:2006+A1:2015 real activities, or documentation that was back-filled after the fact?
  8. Can your technical file be navigated by a stranger against the Annex II structure in under ten minutes?

Any question answered with a no is a month that will be added to your timeline. Any question answered with a yes is a month you have already saved.

Frequently Asked Questions

Is twelve months from kickoff to CE mark realistic for any SaMD startup? It is realistic for Class IIa SaMD with a narrow intended purpose, a completed Phase 1, disciplined founders, and a Notified Body with capacity. For Class IIb and Class III SaMD, twelve months is not realistic because the clinical evidence expectations and the conformity assessment depth are larger. For teams without a Phase 1 behind them, twelve months is not realistic because the product-market fit work cannot be compressed into the regulatory project.

Does the twelve months include the Phase 1? No. The twelve months start when the MDR clock starts — the day the founders commit to the medical intended purpose and begin the compliant build. The Phase 1 preceded that clock by roughly another twelve months, during which the product was used for research purposes without medical claims. Including Phase 1, the total elapsed time from the company's founding to the CE mark was closer to twenty-four months.

How did the team afford twelve months of MDR work? Phase 1 was funded by hospital pilots. The data generated in Phase 1 produced the evidence of product-market fit that unlocked a small funding round for Phase 2. The twelve-month compliant build was funded by that round plus continuing hospital revenue. This is the two-phase approach working end-to-end — Phase 1 pays for itself and unlocks the funding for Phase 2.

Could the team have done this without a Notified Body? No. Class IIa under the MDR requires a Notified Body for conformity assessment. Only Class I devices can be self-certified, and SaMD under Rule 11 is rarely Class I. Any founder being told they can self-certify a Class IIa SaMD is being given bad advice.

What was the biggest risk to the twelve-month timeline? Scope creep in the intended purpose. The pressure to broaden the indication came from investors and from the sales team at Month 7, exactly when the clinical evaluation was being built. Holding the narrow indication under that pressure is the single decision that most affected the final timeline.

Is the Notified Body audit result — four findings — typical? Yes. A well-prepared Class IIa SaMD audit typically produces a handful of findings, most of them minor. Zero findings is possible but rare, and it usually signals either an exceptionally clean file or an under-scoped audit. Four findings, one major and three minor, is a normal clean result for a disciplined first-time submission.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 51; Article 61; Annex II; Annex VIII, Rule 11. Official Journal L 117, 5.5.2017.
  2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
  3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes.
  4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
  5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.

This post is part of the MedTech Startup Strategy & Product-Market Fit category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The company described in this case study has been anonymised per the rules of this blog; the sequence, the decisions, and the outcome are real. The MDR is the North Star for every claim in this post — the harmonised standards referenced are tools that provide presumption of conformity, not independent authorities. For startup-specific regulatory support on SaMD timelines, Zechmeister Strategic Solutions is where this work is done in practice.