The QMS a medtech startup actually needs in year one

Ask what a medtech startup needs from a QMS and you will usually get an answer scaled for a company that does not look anything like yours. Twenty-eight SOPs. A supplier audit programme with site visits. A training matrix covering roles you have not hired. A document hierarchy diagram.

None of that is wrong. It is what a mature ISO 13485 organisation looks like, and if you are still shipping in five years you will get there. But handing it to a team of five in year one is how good teams end up with a quality system that exists as a folder nobody opens, which is worse than a small system people actually use.

So here is the useful version: the order to build things in, and how thin each part can honestly be at your size.

One thing to be clear about first

There is a version of this advice that gets startups into trouble, and it is the version that tells you which parts of the standard you can postpone. That is not what follows, so it is worth drawing the line early.

Once you are operating under ISO 13485, the elements of the quality system are required to exist. The quality manual is clause 4.2.2 and it is mandatory whatever its length, which catches people out because ISO 9001 dropped that requirement in 2015 and ISO 13485 did not. Supplier controls are clause 7.4, and clause 4.1.5 covers outsourced processes, both of which apply from the moment you rely on a supplier rather than from the moment you feel ready. No clause starts applying in month nine.

What genuinely scales with your size is depth. A quality manual can be four pages or four hundred. Supplier control can be a register with a rationale per entry, or an audit programme with site visits. Year one is about getting each element to exist at a depth your actual risk warrants, in an order that means you are never claiming a system you do not have.

That is the distinction this article runs on: build order and depth, not permission to skip.

The principle underneath all of it

A QMS is a machine for answering questions about the past. Who decided this, when, based on what, and did anyone check. That is the whole job, and the clauses are elaborations of it.

Which gives you a test for how much effort a thing deserves right now: does this create a record that will answer a question later, or does it only describe an intention to create records? Intentions are cheap and they do not survive audit. Records are the product.

Months one to three: the parts that have to exist from the start

An intended use statement. One or two sentences. It drives your classification, your risk file, your claims, and your regulatory pathway, and it deserves more thought than its length suggests. If you are unsure where your product sits, our classifier will tell you, including when you are close enough to a boundary that a specialist opinion is the right call.

A quality manual, and a short one. Clause 4.2.2 asks for the scope of your QMS, justification for anything you exclude or do not apply, your documented procedures or references to them, and a description of how the processes interact. At your size that is a handful of pages. Write it early rather than late, because the exercise of stating what applies to you and what does not is genuinely clarifying, and doing it in month two is much easier than reverse-engineering it in month eleven.

Document and record control. Clauses 4.2.4 and 4.2.5. The moment you approve your first requirement you have a controlled document, so this cannot trail behind the documents it governs. Versioning, approval before issue, effective dates, protection from alteration, and a way to see what the approved version was on a given date.

Requirements, written down and approved. Not a backlog. A controlled list of what the product is meant to do, with a name against each approval and a version history when they change. This is the spine everything else attaches to, and the single most painful thing to reconstruct later, because by month nine nobody remembers why REQ-12 was worded that way.

A risk register that is actually a register. Living, updated, with hazards, severity, probability, and mitigations. Not a document you wrote once for a grant application. ISO 14971 is the reference and it is more readable than its reputation.

A supplier and dependency register. This one surprises software teams, because it sounds like a manufacturing concern. It is not. Your hosting provider, your third-party libraries, and anything processing user data on your behalf are suppliers, and you depend on them from your first deployment. Clause 7.4 wants evaluation criteria and records of evaluation; clause 4.1.5 wants control over outsourced processes proportionate to risk. In year one that is a register with what each dependency does, why you consider it acceptable, and what you would do if it went away. It is an afternoon. It just cannot be an afternoon in month ten.

Months four to eight: the parts that activate as you ship

Verification evidence linked to requirements. If your team writes automated tests you are most of the way there. What turns test output into verification evidence is the link: this run, verifying this requirement, at this version. Teams consistently underestimate how much of IEC 62304 they already do and how little of it they record. Our IEC 62304 guide covers the specifics.

Issues, complaints, and CAPA. The moment you have users you have complaints and defects, and the standard cares a great deal whether you investigate them or merely fix them. Fixing addresses the instance; corrective action addresses the cause. You want that distinction recorded before the first serious bug rather than after it.

Release records with enforced approvals. A structured gate at ship time: requirements verified, risks reviewed, approvals signed by named people with timestamps. A release gate a human has to remember to run is a release gate that gets skipped in a hurry, and hurried releases are exactly the ones you get asked about.

Training records. Clause 6.2, and the trigger is people doing work that affects quality, so in practice this starts with your first hire rather than at a fixed month. Short but real: who has been trained on which procedure, when, and re-training when a procedure changes.

Design history, assembled as you go. Not a document written at the end. The design history file is a view over records you already hold, provided the records are linked. If they are not, it is a three-week archaeology project.

Months nine to twelve: the cycle parts

These two genuinely run on planned intervals rather than continuously, so a first pass inside year one is a reasonable target.

Internal audit. Clause 8.2.4. One honest pass against the standard to find your own gaps. Findings you discover yourself cost days; findings an auditor discovers cost months.

Management review. Clause 5.6, with defined inputs and recorded decisions. Twice a year is plenty at this size. It feels like theatre until the first time it catches something.

What stays deliberately thin

This is the list that replaces "what can wait", because at your size the honest answer is about depth rather than existence.

Your quality manual is pages, not binders. Your supplier controls are a register with reasoning, not an audit programme with site visits. Your SOPs are a few documents describing how you actually work, rather than one per clause. Your training records are a matrix, not a validated learning platform. Statistical process control is almost certainly not applicable, and saying so with justification in your quality manual is itself the correct move rather than an omission.

And a dedicated quality hire can usually wait until you are approaching first certification or first submission.

One more, said even though we sell the alternative: you do not need to solve year three in year one. Buying a system sized for a 200-person manufacturer because you might become one is how startups end up paying enterprise prices for software their engineers refuse to open.

The failure mode to watch for

It is rarely that a team does not know the rules. It is that the quality system lives somewhere separate from where the work happens, so it drifts. The requirements stop matching the product. The risk register describes a version you shipped past. The traceability matrix was accurate in March.

Drift is a design problem rather than a discipline problem. If maintaining the records is a separate task from doing the work, it loses to doing the work, in every team, at every company. The fix is tooling where the record is a byproduct of the work rather than a chore appended to it. That is worth more attention than feature lists.

You will be fine

Year one is smaller than the internet suggests, but it is wider than most startup advice admits. Everything has to exist. Almost none of it has to be elaborate.

Six things established in the first quarter, five more as you start shipping, two cycle activities before the year is out, and you have a real quality system with real records behind it. Teams your size do this regularly, on ordinary budgets, without a quality department.

The ones who struggle are the ones who waited for a perfect plan, or who were told a mandatory clause was optional and found out during an audit. The ones who do fine start thin, start early, and add depth where their risk actually points.

If you want the honest split of what needs a specialist and what does not, we wrote that one up too.

Book a demo -- a lean QMS built for small teams.