The medtech CTO's first 90 days — the regulatory decisions founders botch

Three weeks into a new CTO role at a Class IIb diagnostic startup, a founder I was advising asked me which SOP template we should use. That wasn't the question. The question was which of the seventeen decisions already made in his engineering process were going to cost him six months at submission.

Nobody hands you a regulatory playbook when you take the technical lead on a medtech company. You inherit a device classification (or don't), a target market (usually optimistic), a team with varying regulatory literacy, and an expectation from the board that the first submission lands in 18 months. The regulatory framework is not optional, and it doesn't wait for a convenient point in the sprint to become relevant.

The decisions you make in the first 90 days set your regulatory trajectory for the next three to five years. Teams that get this right spend those years building a defensible device. Teams that don't spend them rebuilding documentation they should have been generating from day one.

Days 1–30: get the classifications right before anyone writes code

Three classifications determine almost everything downstream. Device classification. Software safety classification. Regulatory pathway. Wrong answers on any of these in the first 30 days will cost you a quarter of engineering time later.

Device classification. FDA (Class I, II, III) and EU MDR (Class I, IIa, IIb, III) both key off intended use and risk — not the technology. A clinical decision-support tool that recommends dosing is not the same device as one that displays reference information, even if the code is 90% shared. The classification question isn't "what does it do." It's "what claim do you want to make in labelling." Write the draft indication for use before anything else. The classification follows from the indication.

Software safety class. IEC 62304 Class A, B, or C, driven by the severity of harm a software failure could contribute to, evaluated against your ISO 14971 analysis. This classification is not set at the system level; it's set per software item under Clause 4.3. Teams that assume a uniform class for the entire SaMD miss the segmentation opportunity — a Class C system can contain Class A items like log formatters and display utilities. Segmentation saves months of verification effort if it's defensible. It also has to be actually defensible.

Regulatory pathway. 510(k), De Novo, PMA, EUA, CE via notified body. Each has different evidence requirements, different timelines, different risk. Don't assume 510(k) because it's cheaper. Assume nothing until you've looked for a predicate device in the FDA database and confirmed one exists with the same intended use, the same technological characteristics, or a defensible argument for substantial equivalence on both. A Q-Submission meeting with FDA costs you three weeks of preparation. It's cheaper than nine months of pathway arguments during review.

Finish month one with confident, documented answers on all three. Not confident because a consultant said so. Confident because the reasoning is written down and has been stress-tested.

Days 31–60: architect the quality infrastructure engineering will run on

Month two is not the month you write SOPs. It's the month you make structural decisions that are expensive to reverse.

QMS scope. Explicitly defined. Design controls always. Risk management always. Document and change control always. Other elements (CAPA, supplier controls, management review) scoped to your current stage with a written plan for when each expands. "ISO 13485 certified" with undefined scope is a sentence that causes problems later.

Where engineering decisions live. This is the tool decision that actually matters, and it's the one most CTOs make badly because they treat it as a tooling question. It isn't. It's an architecture question. If design inputs, design outputs, risk controls, and verification evidence live in five disconnected systems maintained by different people, you're building reconciliation debt from day one. If they live in a connected record where changes cascade structurally, the design history writes itself as engineering happens.

Risk management process. Decide now how risk connects to design decisions. ISO 14971 is not a document you write before submission. It's a live hazard analysis that engineers see when they make design calls. If risk analysis lives on one person's laptop and engineers never open it, risk controls become retroactive, and retroactive risk controls are the most common finding in design controls inspections.

Days 61–90: make the first engineering decisions in the new process

Month three is about operating the infrastructure you set up in month two. Three deliverables by day 90.

Requirements baselined. Not complete. Baselined. A documented, reviewed set of design inputs for at least the first iteration of the device, with sources traced to user needs, risk controls, and regulatory clauses. If you can't produce this by day 90, the infrastructure decisions from month two weren't the right ones.

First design review on the record. Scheduled in month two. Executed in month three. With at least one independent participant. With a written record of what was reviewed, who attended, what was decided, and what actions came out. Running the first design review against an empty record is a sign the first 60 days didn't produce the outputs they should have.

V&V strategy documented. How will you demonstrate your design outputs meet your design inputs? What's the unit / integration / system test allocation? What coverage targets apply to Class B and Class C items? What's in scope for formative vs summative usability? This is strategy, not protocol — the specifics come later. The strategy needs to exist before the first serious line of production code.

The three patterns CTOs botch every time

I've watched the same three patterns cost different companies the same 12 months.

Building first, documenting later. The instinct is to prove the technology before investing in regulatory infrastructure. Result: an engineering record that doesn't reflect the decisions actually made, because those decisions happened in Slack, whiteboards, and code comments never connected to a formal design record. Reconstructing from memory before submission is slower and less defensible than building it in real time — and the reconstruction is always visible to reviewers who've seen this pattern before.

Treating regulatory as a handoff. Build the device, hand it to a consultant to "write up the documentation." Works for companies with comprehensive internal records. Doesn't work for companies whose engineering decisions weren't tracked with regulatory structure in mind, which is most early-stage teams. The consultant becomes an archaeologist, piecing together a design history from incomplete evidence. You pay consultant rates for archaeology work, and the output still has gaps.

Wrong scope for the wrong stage. Building a full ISO 13485-compliant QMS at 10 people is over-engineering. Building nothing because "we'll deal with compliance later" is under-engineering. The right scope at each stage is the minimum that produces defensible design controls evidence for your current program and scales without a rebuild when you add post-market surveillance or a second product line.

The tool decision, restated

Most consequential tool decision in the first 90 days is not your IDE, not your project management tool, not your design tool. It's the platform where engineering decisions live and produce their documentation.

Teams that make design decisions in MANKAIND produce a design history as a natural output of engineering. Requirements connect to risk controls from creation. Design changes cascade through affected documentation the moment they're made. The traceability matrix rendered for submission comes from the live record, not an assembly project.

That isn't a documentation tool. It's the engineering environment your team works in. The difference between picking it on day one and picking it on day 300 is the difference between a design history that builds with your product and a design history that has to be reconstructed from it. I've watched this decision made both ways. The second way always costs more than the first.