The phrase "software moat" appears in a striking number of medical device pitch decks. It usually means one of three things: the company has proprietary algorithms, the company has deep software integrations that would be costly to replicate, or the company has invested heavily in regulatory compliance infrastructure that competitors would have to rebuild from scratch. All three can be legitimate competitive advantages — but they require very different verification approaches, and in my experience, founders who invoke "software moat" are not always clear on which of the three they actually mean. That ambiguity is a diligence flag.
The first question I ask about any medical device software company is: how is this software classified under FDA's SaMD framework? Software as a Medical Device has a specific regulatory meaning, and classification — Class I, II, or III — determines whether 510(k) clearance, De Novo designation, or PMA approval is required. Classification is not just a compliance detail. It tells you something important about the risk profile of the intended use, the evidentiary standard the company must meet, and the competitive dynamics: Class II clearance is achievable for well-resourced early-stage companies; Class III PMA is a multi-year process that requires randomized controlled trial data and changes the capital requirements significantly.
I then ask about IEC 62304 compliance posture. IEC 62304 is the international standard for medical device software lifecycle processes, and FDA expects 510(k) submissions for software-containing devices to demonstrate compliance. This is where the marketing slide and the 510(k) submission most often diverge. Companies that have not built IEC 62304-compliant software development lifecycle documentation — version control, change management, risk management processes per ISO 14971, software-of-unknown-provenance (SOUP) identification — will face significant remediation costs before they can submit. For an early-stage company, that remediation can run six to twelve months and require substantial engineering re-prioritization.
Three questions are reliably diagnostic in my first technical conversation with a medical device software founder. First: has the company received a Breakthrough Device Designation, and if so, why? This is not to assess whether they have the designation — many good companies don't — but to understand whether they have thought carefully about their regulatory pathway strategy and the tradeoffs between different designation routes. Second: what is the company's SOUP management process? Software of unknown provenance — open-source libraries, third-party components — must be tracked, evaluated for safety, and documented in the device master record. Founders who answer this question fluently have done the regulatory engineering work. Founders who ask what SOUP means have not. Third: what happens to the device software classification if the intended use expands into new clinical contexts? Many early-stage medical device companies have intentions to expand their indication over time. Indication expansion often triggers reclassification and a new regulatory pathway — a point that materially affects long-term capital planning and competitive dynamics. Founders who have modeled this proactively are thinking about software development the way it needs to be thought about in a regulated context: not as a startup engineering problem, but as a quality system problem that must be managed from day one.