Skip to content

Resources · Guides · P-6

The Health Tech Founder's Regulatory Playbook: Where to Start, What It Costs, When You'll Launch

Last reviewed:

Status as of 2 July 2026, next review 1 October 2026 or immediately on adoption of the UK's Medical Devices (Amendment) Regulations 2026, whichever is sooner.

Most health tech founders don't fail regulatory strategy because they misunderstand a rule. They fail it because they discover the rules too late to plan around them: a Notified Body queue that's longer than the fundraising runway, a predicate device that doesn't exist, a cost estimate lifted from a single founder's anecdote in a Slack group rather than an attributed figure, and then presented to a board as if it were reliable. This guide exists to move that discovery earlier. It isn't meant to give you deeper regulatory detail than you need at the decision stage; it's meant to give you the actual decisions, in the actual order you'll face them, with the actual numbers attached.

This is the pillar page for everything else on this site about strategy, sequencing, and budget. If you want the full depth on classification, CE marking mechanics, FDA pathway selection, or multi-market dossier reuse, each of those has its own complete guide, linked throughout. This page is the map that tells you which of those guides you need first, and in what order.

In short: Regulatory strategy for a health tech startup reduces to four decisions: what your product is (classification), where to launch first (EU, UK, or US, decided by class per system), what to budget (industry figures commonly cite EUR 120,000–300,000 and 12–18 months for CE Class IIa–III; USD 150,000–350,000 and 6–12 months for a 510(k)), and how to avoid first-pass failure.

On this page: The through-line: what founders discover too late · Decision one: what is this product? · Decision two: where do we launch first? · Decision three: what's the honest budget? · Decision four: build, buy, or blend? · The failure-mode gallery · The first 90 days · Fundraising and regulatory diligence · FAQ

The through-line: what founders discover too late

Every founder we talk to eventually asks some version of the same question: "where do I even start?" It rarely sounds like a regulatory question when it's first asked. It sounds like a fundraising question, a hiring question, or a product-roadmap question that turns out to have a regulatory answer buried inside it. A board member asks when you'll be revenue-generating in the US. A co-founder wants to know if next quarter's feature (an AI-generated summary, a risk score, a "detects early signs of") changes what you're building. An investor's diligence questionnaire has a line item, "regulatory pathway and timeline," that nobody on the founding team has priced out yet.

The pattern that recurs across the founders we work with isn't that they get the regulation wrong. It's that they get the sequence wrong, because nobody told them the sequence mattered as much as the substance. A founder who spends four months building a beautiful MDR technical file for a product that was never going to need Notified Body review at all has wasted four months. A founder who commits to a 510(k) predicate comparison before checking whether a genuinely comparable predicate exists has built a submission strategy on sand. A founder who lets a wellness-labeled claim drift into device territory over a series of small marketing edits — "track your sleep" quietly becoming "detect signs of sleep apnoea" — discovers the regulatory consequence only once the product is already in front of users, not while the claim was still easy to walk back.

This guide is built around the fear that sits underneath most of those mistakes: first-pass failure. Not failure in the abstract; failure at the specific moment a Notified Body or FDA reviewer sends your submission back with findings, adding months to a timeline you'd already told your board and your investors. That fear is rational, and it's also addressable, earlier than most founders realize. That's the actual argument of this page: the decisions that prevent first-pass failure are made months before you submit anything, not during review.

What follows is organized as four decisions, in the order you'll actually face them, followed by a gallery of the specific failure modes that catch first-time teams, a concrete first-90-days plan, and a look at what investors actually check when they diligence your regulatory story. If you're a regulator reading this for precision, you'll find it: every figure here is sourced and attributed, every term is used correctly. But this page is written for founders, not for regulators, and it says so on purpose. The goal is a founder who can walk into a board meeting or a fundraising conversation and talk about regulatory strategy like it's a resourcing decision they've already made, not a fog they're still standing in.

the free MedTech Compass can give you an AI-generated first read on where your product likely sits against the decisions below — classification, likely first market, rough budget range — based on the inputs you provide. It is a starting point, not a validated determination: treat it as the fastest way to get oriented before the rest of this page, or before a working conversation with someone who can review your actual product and claims.

Decision one: what is this product?

Every other decision in this guide is downstream of this one, and it is the decision founders most often try to skip or shortcut, because it feels like the answer should be obvious from what the product does. It isn't. Classification doesn't follow from your product's technical sophistication, or your own sense of how "medical" it feels to build. It follows from your claims, tested against a specific set of rules that differ by jurisdiction.

Under EU MDR, the test runs through Annex VIII's 22 classification rules across four device groups (non-invasive rules 1–4, invasive rules 5–8, active rules 9–13, special rules 14–22). For standalone software specifically, Rule 11 is the one that matters most, and it typically pushes decision-supporting software to Class IIa or higher the moment the software's output is used to inform diagnosis or treatment decisions rather than simply organizing or displaying existing information. Under FDA's framework, the equivalent question is whether your software meets the statutory device definition at all, and if so, which of three practical buckets it falls into: general wellness (exempt), the narrow four-part clinical decision support exemption under the 21st Century Cures Act, or Software as a Medical Device requiring clearance or authorization.

Two things about classification catch founders consistently. First, classification follows claims, not code. The same underlying model can sit in a wellness bucket or a regulated-device bucket depending entirely on what your marketing copy, your app store listing, and your investor deck say it does, not on your architecture. A diagnostic-grade algorithm marketed with careful, general wellness language can genuinely stay outside device regulation; a modest feature marketed with a single "detects early signs of" line can pull an entire product into a regulated category. Second, founders routinely classify against an idealized future roadmap version of their product rather than what's actually launching first, which quietly obsoletes a fundraising timeline built around the wrong classification.

This pillar deliberately doesn't re-run the full classification walkthrough here. That depth belongs to, and already exists in, the pillar on MDR Rule 11 and the FDA device rules, which covers the full Annex VIII rule set, FDA's SaMD risk categorization, and a worked gallery of borderline cases. What this chapter is for is placing classification in sequence: it is the decision that determines which of the rest of this page's chapters actually apply to you, so it has to happen first, and it has to happen honestly, against the product you're actually shipping this year rather than the one on your Series B roadmap.

The AI Act layer: for AI products, MDR classification isn't the whole story

If your product is AI-driven — and most of the worked examples in this guide are, from the AI-assisted triage tool to the "risk score" feature — the EU adds a second regime on top of the MDR: the EU AI Act (Regulation (EU) 2024/1689). Under its Article 6(1), an AI system that is, or is a safety component of, a product covered by the MDR and subject to third-party conformity assessment — in practice, Class IIa and above — is automatically a high-risk AI system. The conformity work is largely delivered through the MDR route rather than a separate parallel certification, but it adds real requirements (risk management, data governance, logging, transparency, human oversight) and real cost that an MDR-only budget misses. An AI founder who budgets the MDR path alone is under-planning.

Two pieces of the AI Act apply or arrive on fixed dates regardless of the postponement debate: Article 4's AI-literacy obligations for providers and deployers have been in force since 2 February 2025 (in force, though Article 4 itself carries no attached fines regime), and Article 50's transparency obligations take effect on 2 August 2026. The high-risk deadlines are the moving part:

Status (updated 25 July 2026): The Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026. From entry into force, the postponed dates are the legally binding ones: 2 December 2027 for Annex III stand-alone high-risk systems, and 2 August 2028 for high-risk AI in regulated products — including medical devices under Article 6(1). The original 2 August 2026 and 2 August 2027 deadlines are superseded. Plan against the postponed dates.

If you take one thing from this chapter into a board or co-founder conversation, make it this: "what class is this" is not a compliance question you can defer until closer to launch. It is the question that determines your regulatory budget, your realistic timeline, and your first market. As the fundraising chapter below covers, it's also what a diligence-minded investor is going to ask you about before they sign a term sheet.

Decision two: where do we launch first?

Once you know roughly what your product is, the next question founders ask is almost always phrased as an ambition question: which market matters most to us. It's actually a sequencing question with a different right answer. The market that gets you a CE mark, UKCA mark, or FDA clearance fastest at a stage where your evidence is thinnest is not necessarily the market with the biggest addressable opportunity, and treating those as the same question is one of the more expensive strategic mistakes a founder can make.

The three systems, compressed

EU (MDR)UK (legacy framework)US (FDA)
Classification logicAnnex VIII, 22 rules, Class I–IIIBroadly mirrors pre-Brexit EU rules, with active divergence underway (see below)Device definition, then 510(k)/De Novo/PMA pathway choice
GatekeeperNotified Body (Class IIa+)Approved Body (where required)FDA
Typical timeline, Class IIa-equivalent software12–18 months (industry-cited range)Can be materially shorter where legacy Class I self-certification currently applies — see the discussion below6–12 months for a straightforward 510(k) (industry-cited range)
Typical cost, Class IIa-equivalent softwareEUR 120,000–300,000 (industry-cited range)Lower where self-certification currently applies; broadly similar to EU where a UK Approved Body is requiredUSD 150,000–350,000 including consulting (industry-cited range)
What it grantsCE mark, EU market accessUKCA mark, GB market access (Northern Ireland follows separate rules)Clearance (510(k)), grant/authorization (De Novo), or approval (PMA); US market access

All figures in this table are industry-cited ranges, not Venitara quotes or commitments — they vary significantly with how mature your technical file and evidence base already are when you start, and they are repeated with that caveat every time they appear on this page, not just here.

The UK arbitrage, and why it's worth watching closely, not treating as permanent

This is one of the more consequential facts in the market-sequencing decision, and it deserves an honest, current status rather than either a false alarm or a false sense of permanence. The UK's post-Brexit medical device framework, under UK MDR 2002 (as amended), currently retains transitional arrangements that let some standalone software products continue to self-certify under legacy Class I rules even where the equivalent EU MDR classification — typically Class IIa under Rule 11 — would require Notified Body involvement. For an evidence-thin early-stage team, that has meant a real, currently exploitable divergence: a faster, cheaper first launch in Great Britain than the same product would get in the EU.

None of this means the UK route is a passing curiosity — for the right team, it remains one of the sharpest sequencing opportunities available anywhere in this guide. It means treating it as a live, currently-available option to evaluate against your own timeline, revisiting that evaluation as the regulatory picture develops, rather than either assuming it will vanish on a specific date or assuming it's a permanent structural feature of your go-to-market plan.

Worth watching on the EU side too: the "Class IIa under Rule 11" comparator used throughout this section describes today's binding EU rule, and it's accurate as the current state. But it isn't necessarily permanent either — on 16 December 2025, the European Commission published a proposal (COD 2025/0404) to simplify MDR and IVDR, including revising Rule 11 so that software would start at Class I and be up-classified based on intended use, rather than starting at Class IIa as it does today. This is an early-stage proposal that still needs European Parliament and Council agreement, with multiple trackers estimating 2027 at the earliest for any amended Rule 11 to take effect — it does not change today's rule, and Class IIa remains the correct default to plan against right now. It's flagged here as a "watch this" item, the same way this guide tracks the AI Act's Digital Omnibus postponement in Decision One above, because it's directly relevant to the classification logic this whole section relies on.

One narrower EU-side note: if you're acquiring or transitioning a product that still holds a legacy MDD certificate, the MDR transitional deadlines under Regulation (EU) 2023/607 govern how long that certificate keeps working — 31 December 2027 for Class III and Class IIb implantable devices, 31 December 2028 for other device classes. Irrelevant to a net-new software product, but a real diligence item in an acquisition.

For teams weighing this alongside a fourth market, the pillar on one dossier across three markets covers how evidence built for a UK or EU launch reuses toward FDA and SFDA submissions, which matters regardless of which market you launch in first.

A worked example: same class, opposite answers

It's easier to apply this decision with two concrete cases in front of you rather than a general framework alone, so consider two products carrying an identical EU MDR classification that land on opposite sequencing decisions.

The first is a Class IIa AI-assisted triage tool built by a two-person founding team, pre-revenue, with no US investor relationships and thin real-world evidence beyond a retrospective validation study. For this team, the UK legacy arbitrage described above is close to ideal: a faster, cheaper first launch generates real-world usage data that materially strengthens the eventual EU MDR clinical evaluation, and there's no competing pull toward a US-first sequence. This team's runway and product maturity make an accelerated UK-first launch a strong, currently-available option.

The second is a Class IIa remote patient monitoring platform built by a Series A team with two US-based board members and a signed pilot with a US health system contingent on FDA clearance. For this team, the UK arbitrage is largely irrelevant, because commercial pressure and predicate availability point decisively toward a US-first 510(k) sequence. A UK launch would generate evidence and revenue in a market that isn't where this team's next twelve months of commercial and fundraising pressure actually sit, so the EU MDR build proceeds in parallel, but as the second priority, not the first.

The lesson these two cases share is the one this chapter opened with: classification tells you what's required in each market, it doesn't tell you which market to prioritize. The constraint that actually decides sequencing — evidence thinness in the first case, investor and pilot pressure in the second — is very often not a regulatory fact at all.

Decision three: what's the honest budget across markets?

Founders ask "how much will this cost" expecting a number and generally get, correctly, a range — and the range is wide enough that a single headline figure would mislead more founders than it helped. What actually matters at the decision stage is not memorizing the range but understanding what drives it, so you can budget against your specific starting position rather than an industry average that assumes you're starting from nothing.

Here is the comparison this chapter promises, built as an actual table rather than described in prose:

MarketTypical cost rangeTypical timelineBiggest cost driverSource note
EU (CE mark, Class IIa–III software)EUR 120,000–300,000 (industry figures, not a quote)12–18 months (industry-cited range)QMS build (if starting from nothing) and clinical evaluationIndustry figures, commonly cited by regulatory consultancies and market analysts; see CE Marking Cost and Timeline for Medical Software for the artefact-by-artefact allocation
UK (legacy Class I route, where currently applicable)Lower where self-certification applies; broadly similar to EU cost where a UK Approved Body is requiredCan be materially shorter than the EU range where legacy self-certification currently applies — see the discussion in Decision Two aboveWhether you still qualify for self-certification at all, and how the regulatory picture developsIndustry-cited range; this route is currently open but actively developing, not a guaranteed stable long-term cost baseline
US (510(k) clearance)USD 150,000–350,000 including consulting (industry-cited range)6–12 months from submission to clearance, on top of FDA user fees (industry-cited range)Predicate availability and the depth of substantial-equivalence testing requiredIndustry figures, not a quote; see Why Most 510(k)s Get an Information Request for what drives variance inside this range

Every figure in this table is repeated with its attribution intact every time it appears in this document — none of it is a Venitara price quote, and none of it is a guaranteed outcome for your specific product.

What actually moves you within the range

Two variables explain most of the spread in every market above: how mature your quality management system and documentation discipline already are when you start, and how much of your evidence base you're building from scratch versus reusing. A team with a genuinely blank page — no QMS, no documented risk management process, no clinical evaluation started — sits at the top of every range in the table. A team that has run disciplined design and development documentation contemporaneously, rather than reconstructing it before submission, can land meaningfully below the midpoint on both cost and time in every market. That's not because they found a shortcut; it's because they aren't paying to reconstruct evidence that should have existed from day one. One US-side change removes a whole category of duplicated work here: FDA's Quality Management System Regulation (QMSR) has been the operative US quality regime since 2 February 2026, revising 21 CFR Part 820 to incorporate ISO 13485:2016 by reference — so a QMS built to ISO 13485 now serves both the EU and US quality baselines rather than needing a separate FDA-specific build.

For the EU route specifically, the pillar on CE marking medical device software breaks the EUR 120,000–300,000 range (industry figures, not a quote) down artefact by artefact — QMS build, technical documentation, clinical evaluation, Notified Body fees, PRRC and ongoing compliance — with a worked cost example for a five-person team starting from nothing. For the US route, the pillar on FDA clearance for software as a medical device does the equivalent breakdown for the USD 150,000–350,000 range (industry-cited figures), including why predicate availability specifically is the single biggest lever on both cost and the 6–12 month timeline.

Companion asset: the regulatory budget and timeline worksheet. This comparison table gives you the market-level picture, but your actual number depends on your specific starting position — your current QMS maturity, your evidence base, your device class, and which markets you're sequencing and in what order. We've built a structured worksheet that walks through the same cost drivers above against your own product's specifics, so you leave with a working budget range rather than an industry-average headline figure. One example of the row-level detail it tracks: Market | Stage | Low estimate | High estimate | Confidence note — e.g., EU (CE, Class IIa) | QMS not yet started | EUR 180,000 | EUR 300,000 | Industry-cited range; assumes no existing documentation to reuse. It's available through the free MedTech Compass and contact flow (gated — it collects your basic product and stage details so the output is actually useful, rather than a generic template); any figures it returns are a starting point for a working conversation, not a quote.

Ongoing costs are a separate line, in every market

A pattern worth naming directly: every figure above covers the path to initial certification or clearance, not what it costs to keep the product on the market. PRRC and post-market surveillance in the EU, EUDAMED registration and upkeep (mandatory since 28 May 2026), periodic reporting obligations for higher device classes, and vigilance system maintenance all persist for the life of the product, and teams that budget only to "first certification" or "first clearance" consistently under-plan their actual regulatory burn rate. Budget these as a distinct, ongoing line from day one rather than discovering them after the initial certification cost has already been spent.

The hidden line items founders miss most often

Three specific gaps come up repeatedly in conversations with founders after the fact, and all three are cheap to plan for in advance and expensive to discover late. Translation costs are the first. EU instructions for use and labelling need translation into the official languages of every member state where you intend to sell, which is a real and often underestimated line item once you're targeting the full EU market rather than one or two countries at launch. Post-market clinical follow-up is the second: it's not a one-time cost but an ongoing obligation scaled to your device class, and it's frequently budgeted as though certification is the finish line rather than the start of a continuing evidence-generation cost. The third is the ongoing cost of maintaining your technical file as a living document. Every material change to the software, including some updates that don't feel "regulatory" from an engineering perspective, may need to be assessed against your existing certificate, and that assessment work doesn't stop once you're CE marked or cleared.

What a first-pass failure actually costs, in budget terms

The cost table above assumes a submission that proceeds without a significant returned finding. It's worth being explicit about what happens to both the cost and timeline figures when that assumption doesn't hold, because it reframes how founders should think about "front-loading" spend on documentation quality. A Notified Body or FDA reviewer returning a submission with significant findings doesn't just cost the time needed to address those findings. It costs a second full review cycle, and in a capacity-constrained system, that second cycle can add materially more total time than the weeks it would have taken to close the same gaps before first submission. The same logic applies to cost: additional consulting hours, additional internal engineering time to regenerate evidence, and in some cases additional Notified Body fees for a substantive re-review all sit on top of the original budget line, not inside it. This is the strongest practical argument for treating documentation completeness as a cost-control measure, not just a compliance nicety. In a very literal budgeting sense, it's the cheapest place to spend the marginal hour.

Decision four: build, buy, or blend regulatory capability

Once you know roughly what you're building, where you're launching, and what it costs, the next decision is who does the work. Most early-stage teams face this as a binary — hire regulatory expertise in-house, or outsource it entirely — when the honest answer is usually a blend that shifts over time as the company matures.

The PRRC decision, as a forcing function

Under MDR Article 15, every manufacturer placing a device on the EU market needs a Person Responsible for Regulatory Compliance, and the qualification routes are specific: a university diploma plus one year of relevant experience, or four years of relevant experience without formal qualification. A micro or small enterprise carve-out (Recommendation 2003/361/EC, under 50 employees and under EUR 10 million turnover or balance sheet) allows the PRRC to be external, "permanently and continuously at disposal," rather than an in-house hire. This carve-out is exactly the kind of detail that turns an apparently binary build-vs-buy question into a genuine third option for most seed and Series A teams. You don't have to choose between hiring a regulatory lead you can't yet justify headcount for and having no regulatory ownership at all. PRRC Under MDR Article 15: What to Know covers what small teams consistently underestimate about it, including the exact audit moment where a nominal, under-resourced PRRC gets exposed.

Consultants: what they're actually good for

Regulatory consultants earn their fee doing two things well: catching classification and evidence-strategy mistakes before they're baked into the product, and knowing a specific Notified Body's or FDA division's actual review patterns from recent, current experience rather than general published guidance. What they don't reliably do, regardless of how they're marketed, is expedite a Notified Body's queue or an FDA reviewer's internal timeline — no external party controls that, and claims that imply otherwise are worth treating skeptically from any source. The honest value of good consulting is upstream: fewer, better-targeted rounds of clarification during review, not a faster review itself.

What AI-assisted regulatory tools can, and can't, do

A growing category of software tools now offers AI-assisted help with regulatory documentation — drafting technical file sections, flagging classification signals, generating first-pass risk management content. These tools are useful for exactly what they're built for: speed on the first draft, consistency across large documentation sets, and a lower barrier to starting the process at all for a team with no in-house regulatory writer.

What's worth understanding honestly, and this is a point the category's own vendors generally disclose themselves in their published terms and product documentation, is where the ceiling sits. Tools in this category routinely publish some version of the same limitation: outputs require expert review and are not a substitute for qualified regulatory judgment, and the tool does not itself make or guarantee a classification, clearance, or certification outcome. That's not a criticism of any specific product. It's the category's own stated position, and it's worth taking at face value rather than assuming marketing copy elsewhere on a vendor's site overrides the disclaimer in its own terms. A Notified Body or FDA reviewer evaluates substance and judgment, not template completeness, and a generated first draft that hasn't been reviewed by someone who understands why a specific risk mitigation or clinical claim is or isn't defensible is a starting point, not a finished submission.

The practical framing we'd suggest: treat AI-assisted regulatory tools the same way you'd treat a well-organized template library — genuinely valuable for speed and structure, not a substitute for the judgment that catches the mistake before it's submitted. The free MedTech Compass tool — which, to be plain about it inside a section giving build-vs-buy advice, is our own product — is built and described the same way: an AI-generated starting point, explicitly not a validated determination, useful for orientation before a working conversation with someone who can review your actual product.

A simple framework for the decision

Early-stage, pre-Series A teams with a single-market focus and a straightforward device class are often best served by an external, fractional PRRC (where the small-enterprise carve-out applies) plus targeted consulting engagement at the specific decision points — classification confirmation, evidence-strategy sign-off, technical file review before submission — rather than a full-time regulatory hire. Teams scaling past Series A, running multiple markets in parallel, or sitting in higher device classes generally reach the point where an in-house regulatory lead pays for itself in speed and institutional knowledge, with consultants and tools shifting to a supporting role around that hire rather than carrying the whole function. Neither path is wrong at the wrong stage; the mistake is picking a model sized for a company you aren't yet, in either direction.

How the model should shift as you grow

Think of build-buy-blend less as a single decision and more as a track your company moves along, with three rough stages. At pre-seed and seed, most teams are best served by a fractional or external PRRC where the carve-out applies, a founder or COO who owns regulatory strategy as one of several responsibilities, and consulting engaged narrowly at specific decision gates rather than continuously. Around Series A, as device complexity, market count, or class typically increases, the case for a first dedicated regulatory hire — even part-time or as a senior individual contributor rather than a full department — usually strengthens, particularly once you're running more than one market's submission process in parallel and the coordination overhead of managing external parties starts to rival the cost of the hire itself. Past Series A, for teams in higher device classes or running genuinely parallel multi-market programmes, an in-house regulatory function with consultants engaged for specialized gaps (a specific Notified Body relationship, a specific clinical evidence question) becomes the more common and usually more cost-effective structure. The mistake we see most often is a team staying on the pre-seed model well past the point their complexity has outgrown it, not because the model was wrong at the start, but because nobody revisited the decision as the company changed.

The failure-mode gallery

Founders don't usually fail regulatory review for a single dramatic reason. They fail in a small number of recurring, nameable ways, and every one of them is more expensive to fix after a rejection or hold than before submission. What makes this gallery worth reading in full, rather than skimming for the one that sounds like your product, is that most real submissions carry more than one of these at once. A team with a genuine documentation gap is also more likely to be carrying an unexamined predicate assumption, because both stem from the same underlying pressure to move fast on the product and defer the regulatory groundwork. Here are the six that come up most often, built as an actual gallery, each with what it looks like, why it happens, and how to avoid it.

1. Predicate mismatch What it looks like: A 510(k) submission built around a predicate device that turns out not to be substantially equivalent once FDA reviews the comparison closely — different intended use, different technological characteristics, or a performance claim the predicate doesn't actually support. Why it happens: Teams under time pressure sometimes reach for the closest available predicate rather than the genuinely comparable one, because a clean predicate match is the single biggest lever on 510(k) timeline and cost, and its absence is uncomfortable news to deliver internally. How to avoid it: Confirm predicate suitability as an early, explicit decision, not an assumption carried forward from a competitor's marketing claim about their own clearance, and be honest early if no clean predicate exists. A De Novo pathway pursued deliberately is faster than a weak 510(k) comparison pursued reluctantly and then converted mid-review.

2. Documentation gaps What it looks like: A technical file or 510(k) submission with real, substantive engineering and clinical work behind it, but incomplete traceability between requirements, risks, verification, and validation — the connective tissue a reviewer needs to follow your reasoning, not just see your conclusions. Why it happens: Documentation discipline is the easiest thing to defer under product-development pressure, and it's far more expensive to reconstruct from commit history and old notebooks months later than to capture contemporaneously as you build. How to avoid it: Build documentation practice into the development process itself, not as a pre-submission scramble. This is the single most repeated piece of advice across every regulatory guide on this site, because it is, by a wide margin, the highest-leverage habit available to a founding team.

3. Notified Body backlog What it looks like: An internally well-prepared submission that still runs months longer than planned, not because of anything wrong with the file, but because Notified Body capacity hasn't scaled with MDR's stricter review requirements since the regulation's introduction. Why it happens: This is a systemic, structural bottleneck, not a company-specific failure, but founders who don't plan schedule margin around it treat an external constraint as if it were within their control. How to avoid it: Choose a Notified Body with genuine, current experience reviewing standalone software specifically (not just hardware-heavy devices), ask directly about current submission volume and expected time to first review before committing, and budget schedule contingency specifically around this phase, since it's the phase least within your control and most likely to run long regardless of how well-prepared your internal file is.

4. Wellness-label claims drift What it looks like: A product launched and internally understood as a general wellness tool, whose marketing language gradually acquires device-triggering claims over time — "track your sleep" becoming "detect signs of sleep apnoea" — without anyone treating that as a regulatory decision rather than a conversion-optimization one. Why it happens: Marketing teams reach for language that converts better, and the shift is usually gradual enough that no single update feels like the moment the product's regulatory status changed, even though FDA and MDR both classify based on claims, not architecture. How to avoid it: Audit every public-facing claim — website, app store listing, investor materials, sales collateral — against the wellness/device boundary on a recurring basis, not once at launch, and treat any new clinical-sounding claim as a regulatory review item before it ships, not after.

5. Intended-use scope creep What it looks like: A device cleared or certified for a specific, narrow intended use that a commercial or product team later stretches in practice — using it for a related but uncleared population, condition, or claim — without recognizing that the clearance or certificate doesn't automatically extend with it. Why it happens: Once a product has a clearance or CE mark, it's easy to internally treat that as blanket permission for the product category rather than the specific scope that was actually reviewed, especially as sales teams find adjacent use cases that feel like natural extensions. How to avoid it: Treat any expansion beyond your reviewed intended use — new population, new claim, new clinical context — as triggering a fresh regulatory assessment, not a product update, and build that check into your change-control process rather than your marketing review process alone.

6. Underestimating first-pass cost What it looks like: A submission that gets returned with significant findings, which founders sometimes mentally price as "a delay" rather than what it actually is: a second full review cycle in a capacity-constrained system, which can add materially more total time than if the file had been complete on the first pass. Why it happens: It's tempting to treat a Notified Body's or FDA's first review as an extension of your own quality checking — a safety net that will catch what internal review missed — rather than recognizing that a returned submission re-enters a queue, not a fast lane for corrections. How to avoid it: Invest in getting the file right before first submission specifically, because the cost of a second cycle is disproportionate to the cost of the additional weeks it would have taken to close gaps beforehand, and this is true in both the EU and US systems. On the US side specifically, by one widely cited industry estimate, roughly two-thirds face some form of hold or additional-information request at some point in review, though outright final rejection is a smaller share, commonly cited nearer 10–15%. Submission completeness at first pass is the highest-leverage timeline lever a founder actually controls.

The first 90 days: a concrete plan

This is the chapter meant to be used, not just read: a dated, checklist-style plan for a founder starting from the assumption that regulatory strategy is currently undefined at the company. Adjust the calendar to your own start date; the sequence matters more than the exact dates.

Days 1–15: Get the classification question answered.

  • Write down, in one sentence, exactly what your product claims to do for a user or clinician's health — no architecture description, just the claim as a reader would read it.
  • Pull every public-facing claim about your product (website, app store listing, investor deck, sales collateral) into a single document.
  • Run a first-pass classification check against both EU MDR (Rule 11 if you're software) and the FDA's wellness/CDS/SaMD test, using this guide's Decision One chapter and the medical device classification guide for the EU and US as your working reference.
  • Flag, don't resolve yet, any claim that looks borderline — you're building a list, not making a final call in week one.

Days 16–30: Confirm the market sequencing decision.

  • Run the three-question test from Decision Two: where is the regulatory path fastest given your current evidence, where is your evidence cheapest to generate, and where is the actual near-term revenue or investor pressure concentrated.
  • If the UK legacy route is realistically available to you, confirm it's still current (check for any MHRA developments since this guide's last review date) and make a deliberate yes or no on using it — don't let this decision drift by default just because the route is open today.
  • Decide, provisionally, your first-market sequence and write down the reasoning, not just the conclusion, so a future board conversation can trace the logic.

Days 31–50: Build the honest budget.

  • Use the comparison table in Decision Three, or the companion worksheet described above, to build a working budget range against your actual starting position (QMS maturity, existing documentation, evidence base) rather than the headline industry range alone.
  • Separate one-time certification/clearance costs from ongoing post-market costs in your model — this is the single most commonly missed line item in founder financial models we see.
  • Identify which cost line items are within your control to compress (QMS build, documentation discipline) and which aren't (Notified Body or FDA review timing), and budget schedule contingency specifically around the ones you don't control.

Days 51–70: Decide your regulatory capability model.

  • Confirm whether the MDR micro/small enterprise PRRC carve-out applies to you, and if so, whether an external, fractional PRRC is the right near-term answer rather than a full-time hire.
  • Scope one or two targeted consulting engagements at genuine decision points (classification confirmation, evidence-strategy sign-off) rather than an open-ended retainer, if you're not yet ready for an in-house hire.
  • If you're using AI-assisted regulatory tools for drafting or first-pass documentation, confirm internally who owns expert review of every output before it enters a submission — write this down as a process step, not an assumption.

Days 71–90: Close the documentation gap and set your review cadence.

  • Run a documentation gap analysis against whichever framework applies (MDR technical file, FDA 510(k) requirements), focused specifically on traceability between requirements, risks, and evidence — the gap most likely to catch a first-time team.
  • Set a recurring calendar cadence (monthly is reasonable for most early teams) to re-audit marketing claims against the wellness/device boundary, so claims drift gets caught as a process, not an accident.
  • Schedule the expert conversation this plan has been building toward: by day 90, you should have specific, product-grounded questions to bring to a regulatory strategy conversation, rather than a general "where do we start" question — which is exactly the difference between a productive first meeting and an exploratory one.

Getting the first 90 days right is the highest-leverage regulatory decision most founding teams will make this year — before the file is built, before the Notified Body relationship starts, before a board member asks the timeline question you don't yet have an answer for. Talk through your specific first-90-days plan with an expert →

Fundraising and regulatory: what investors actually diligence

Regulatory strategy stopped being a back-office question for health tech founders once investors started treating it as a runway variable rather than a compliance footnote. What a diligence-minded investor actually checks, particularly one who has seen a regulatory delay blow up a portfolio company's timeline before, tends to cluster around a few specific things, and knowing them in advance changes how you prepare for that conversation.

Classification clarity, stated plainly. Investors want to hear a specific class (or pathway bucket, for US-only teams) and the reasoning behind it, not a hedge. "We believe we're Class IIa under Rule 11 because our software's output directly informs a treatment decision" is a fundable answer. "We're still figuring out if we're a medical device" this late in a raise is a flag, not because uncertainty is unusual early on, but because it signals the classification work hasn't started yet.

A realistic timeline, not an optimistic one. Sophisticated investors know the industry-cited ranges (12–18 months and EUR 120,000–300,000 for CE Class IIa–III, industry figures, not a quote; 6–12 months and USD 150,000–350,000 for a 510(k), industry-cited figures), and a founder who quotes a timeline meaningfully faster than those ranges without a specific, credible reason (an unusually mature starting QMS, a clean predicate already confirmed) reads as either uninformed or overselling. Both are worse than an honest range with the reasoning attached.

Evidence of first-pass discipline. Investors increasingly ask not just "what's your timeline" but "what have you done to avoid a hold or a returned submission," because they've seen the cost of a second review cycle firsthand in other portfolio companies. Being able to point to contemporaneous documentation practice, an early Notified Body or FDA Pre-Submission engagement, or a specific gap analysis already underway is a stronger diligence answer than a confident timeline alone.

Awareness that currently-open routes can change, and active tracking of them. A founder who mentions the UK legacy arbitrage as part of a sequencing strategy, and can speak to its current status and what could change it (the MHRA's draft Amendment Regulations, its international reliance pathway, ongoing MHRA consultations) unprompted, reads very differently to an informed investor than one who presents it as a permanent structural advantage assumed to last indefinitely. The former shows the team is tracking the regulatory environment actively; the latter suggests the plan was built once and hasn't been revisited.

Who owns this internally. Investors want a named owner for regulatory strategy. Even a fractional or external PRRC arrangement counts, provided it's a deliberate structure rather than an absence. "Nobody on the team owns this yet" past a certain stage of fundraising is one of the more common findings that slows or reshapes a term sheet conversation, not because the answer needs to be a full-time hire immediately, but because diligence wants to see the decision has actually been made.

How regulatory risk is reflected in the model, not just the narrative. The most experienced health tech investors don't treat regulatory timeline as a slide in the deck. They expect it reflected in the financial model itself, as a specific assumption about when revenue in each market actually starts, with a credible range around it rather than a single optimistic date. A founder who has already built regulatory cost and timeline into their runway model, including a contingency scenario for a Notified Body or FDA hold, is answering a question the investor was going to ask anyway, before they ask it. This is precisely what the companion budget and timeline worksheet described in Decision Three is built to support: turning the industry-cited ranges into a working number for your own model rather than a line in a pitch deck that nobody has stress-tested.

None of this is about having a perfect answer. It's about having a specific, reasoned one, the same discipline this entire guide has tried to model, chapter by chapter.

Frequently Asked Questions

We're pre-seed and haven't built anything yet. Is it too early to think about regulatory strategy? No — it's actually the cheapest point to start. Classification and market-sequencing decisions made before your architecture is locked in are far cheaper to act on than the same decisions made after a product is built around the wrong assumption. You don't need a full regulatory build at pre-seed, but you do need a first-pass answer to Decision One (what is this product) before your roadmap commits to specific claims, since claims drift is easier to prevent than to unwind later.

How do we know if we should launch in the EU, UK, or US first if we genuinely have no strong preference? Work through the three-question test in Decision Two: where is the regulatory path fastest given your current evidence, where is evidence cheapest to generate, and where is actual near-term commercial or investor pressure concentrated. If those three answers converge on one market, that's usually your answer. If they point in different directions, that's a genuine strategic trade-off worth a structured conversation rather than a default choice, since the "biggest market" instinct is often not the fastest or cheapest one.

What's the single biggest budget mistake founders make? Budgeting only to first certification or first clearance, and treating that as the finish line. PRRC and post-market surveillance costs in the EU, EUDAMED registration (mandatory since 28 May 2026), periodic reporting for higher device classes, and vigilance system maintenance all persist for the life of the product on the market, and teams that don't separate these from one-time certification costs consistently under-budget their actual regulatory burn rate over the following years.

Can an AI-assisted regulatory tool replace a consultant or an in-house hire? Not on its own, and tools in this category generally say so in their own published terms: outputs typically require expert review and aren't presented by the tools themselves as a substitute for qualified regulatory judgment. They're genuinely useful for speed and structure on first drafts, especially for a team with no in-house regulatory writer, but the judgment that catches a mistake before submission, particularly around classification reasoning and clinical claim defensibility, still needs a person who understands why, not just a generated document that looks complete.

How long before a fundraising round should we have our regulatory strategy nailed down? Earlier than most founders assume. Sophisticated investors now diligence regulatory timeline and classification reasoning as a runway variable, not a footnote, and "we haven't started thinking about this yet" reads very differently at a Series A conversation than it does pre-seed. A reasonable target is having Decisions One through Three from this guide answered, even provisionally with clear reasoning, before you open a round where regulatory pathway materially affects your revenue timeline.


Where next: Where to Launch First: EU, UK, or US? · CE Marking Cost and Timeline for Medical Software · Why Most 510(k)s Get an Information Request · Is It a Medical Device? MDR Rule 11 and FDA Rules · CE Marking Medical Device Software: Full Route · FDA Clearance for Health Software: Full Route · Reuse Your CE Technical File for FDA and SFDA

Get your first 90 days right. Book an expert conversation → · Not sure where you stand yet? Start the MedTech Compass →

More on regulatory strategy and sequencing

See where you stand, in about ten minutes.

Free, AI-powered, and every gap comes with a next step.

Start the MedTech Compass