Every tech company entering the healthcare space makes the same mistake. They budget their Software as a Medical Device (SaMD) project like enterprise software, plan for a “launch-and-iterate” cycle, and assume compliance is a final checkpoint before release.
Then reality hits. Hard.
I spent years architecting a clinical decision support platform at scale and working with partners in the industry facing similar challenges. The pattern repeats across startups and enterprises alike: projects run five times over budget and take three times longer than planned.
These aren’t anecdotes. A survey of biopharma executives found that 100% of those who had actually shipped a SaMD product confirmed this brutal math.
Here’s what catches them off guard, and what you can do to avoid that.
The 5x Cost Multiplier Nobody Warns You About#
The gap between expectation and reality in SaMD development is staggering. Nearly half of leaders who haven’t launched a SaMD estimate costs under $1 million. But 57% of those who have actually shipped one report costs exceeding $5 million.
Why such a dramatic difference?
It’s not the initial development. It’s not the cost of writing and testing code.
It’s everything that comes on top.
Unlike typical SaaS products, you can’t simply launch a medical device MVP and move on to the next feature. Every update, patch, and security fix requires regulatory scrutiny under an ISO 13485 certified Quality Management System. You’re not just building software. You’re entering into a perpetual maintenance relationship with regulators.
The yearly post-launch costs often match your original development costs. Factor in ongoing feature upgrades, security testing, hosting, technical support, and mandatory post-market surveillance. When you plan a 3 to 5 year budget, the numbers become sobering quickly.
This isn’t a reason to avoid the healthcare space. It’s a reason to budget honestly and architect smartly from day one. And if you are a start up aiming to enter this space, plan ahead for your runway. Getting regulatory approval is one thing, but this market is typically slow to adapt to changes, so be conservative in your revenue expectations.
The Wellness App That Became a Class IIb Medical Device#
The European Medical Device Regulation fundamentally changed how software gets classified. If you’re building health-related software for the EU market, MDR Rule 11 will probably surprise you.
Classification depends on two factors: how significant the information your software provides is to a healthcare decision, and how serious the patient’s condition is. Software that “drives clinical management” for patients in a “serious” condition gets pushed into Class IIb or even Class III, regardless of how simple your app seems or how low the probability of harm appears.
The result? Software that might have been considered a wellness product or a low-risk Class I device now requires a Notified Body audit and a certified Quality Management System.
An EU regulatory expert put it bluntly: there’s hardly any software left that qualifies as Class I under the MDR.
For startups, this creates a serious barrier to entry. The regulatory hurdles and costs that bigger companies absorb as overhead can be existential threats to smaller teams with novel digital health ideas. Especially if they’re not aware of the full scope of what they’re getting into, and therefore fail to prepare themselves accordingly.
Four Pitfalls of “Non-Device” Software#
The US takes a different approach. The 21st Century Cures Act carved out space for Clinical Decision Support (CDS) software that doesn’t meet the definition of a medical device if it meets four specific criteria:
- Not be intended to acquire, process, or analyze medical images or signals from an in vitro diagnostic device
- Display, analyze, or print medical information from electronic health records without modifying it
- Be intended for a healthcare professional who can independently review the basis for the recommendation
- Enable the healthcare professional to independently review the basis for the recommendation
Miss any one of these, and your “non-device” software becomes a regulated medical device.
I’ve watched teams stumble on each of these pitfalls:
The acquisition trap. Your platform ingests DICOM images from a PACS system for display. You think you’re just showing images, but technically, rendering that image is not as simple as it may seem -> Medical Device.
The modification trap. Your software reduces signal noise, facilitating a smoother display. Helpful for clinicians, but you’ve modified the signal profile -> Medical Device.
The transparency trap. Your machine learning model provides a recommendation but can’t explain its reasoning in a way a clinician can independently evaluate (common when deep learning or neural networks are used) -> Medical Device.
The professional trap. You build a patient-facing app that helps people understand their test results. No healthcare professional in the loop -> Medical Device.
These aren’t edge cases. They’re common paths teams accidentally walk on.
The Accessory Pitfall#
Then there is another trap that catches even experienced teams: your non-device platform may become a medical device accessory without shipping any medical functionality.
If the platform is required for the functioning of your medical device, or if it makes workflow decisions that affect how it operates, regulators may view it as an accessory to that medical device. Accessories are regulated too, and the effective difference in regulatory burden between a medical device and an accessory is often not worth the effort of segregating them.
I’ve seen platforms designed with the best of intentions: abstracting away complexity, providing unified workflow management, optimizing for maximum simplification and reuse. Only to end up creating regulatory liability for the entire stack.
The architecture matters. If your medical device cannot be used without your platform, you’ve crossed the line. This has impact on fundamental design choices that needs careful consideration. Optimize for compliance first, then for simplification and reuse.
Cloud Providers becoming Auditable Suppliers#
Most tech companies treat cloud infrastructure as a utility. Spin up resources, pay the bill, done.
In regulated medical software, your cloud provider quickly becomes a critical supplier that impacts the quality, safety, and regulatory compliance of your device. You do own the risk, even if you don’t own the servers.
This means formal supplier qualification processes. Quality agreements defining roles and responsibilities. Ongoing monitoring of security and performance metrics. Documented evidence in your quality system: supplier assessments, SOC 2 reports, service level agreements.
The cloud operates on a shared responsibility model: the provider secures the cloud infrastructure, but you’re accountable for everything you build on top of it. Configuration, access control, data integrity, encryption choices. These are your responsibilities.
I’ve assessed companies who assumed their cloud provider’s compliance certifications would satisfy regulators. They don’t. You need documented evidence of how you evaluated, selected, and continuously monitor that provider within your own quality system.
The Real Cost of Design Control Failures#
Design control deficiencies consistently rank in the top three FDA 483 observations, often the number one reason. They rank in the top reasons for warning letters too.
In a way this is surprising because design controls are not esoteric. They are foundational engineering practices: defining user needs, creating verifiable requirements, managing design changes. And the regulations have been in place for decades.
The problem isn’t complexity or overhead. It’s culture.
Teams from non-regulated tech backgrounds tend to treat design controls as low-value checkbox activities to complete after the product is built. This approach guarantees regulatory challenges and sets you up for failure.
Design controls create the audit trails that link user needs to validated product features. They’re not bureaucratic overhead. They’re the backbone of a defensible quality system. Without them, you can’t prove that your device does what it’s supposed to do and can be used safely.
Sustained success in MedTech isn’t about passing an audit. It’s about building a culture where quality is deeply integrated in your way of working from day one.
What This Means for Your Architecture#
The regulatory reality has profound implications on how to architect your system. Teams that succeed don’t treat compliance as a final hurdle. They treat it as an architectural constraint from the beginning. They make conscious decisions that optimize for compliance.
Some examples of how this impacts typical architectural patterns:
- Separation of concerns becomes regulatory segregation: isolating what’s regulated from what isn’t, then optimizing regulated parts for stability
- Service design becomes defining regulatory boundaries between components, then ensuring regulatory relevant components can function independently of others
- Change management becomes impact assessment with special attention to regulatory impact, potential safety risks and privacy and cybersecurity aspects
- Infrastructure choices become supplier qualification decisions. Paying attention to supplier independence can be instrumental in reducing risk and managing complexity
The secret to velocity in regulated software isn’t finding loopholes. It’s architecting for the rules.
The Silver Lining#
Is this bad news? Does this mean it doesn’t make sense to try to innovate in healthcare?
No, it doesn’t. It just means we need to be more intentional about it.
A high barrier to entry combined with conservative customers results in long term customer relationships for those that successfully navigate this complex landscape. It is certainly not for the quick win, nevertheless a fertile ground for a sustainable future.
The next article in this series will explore the architecture pattern that addresses these challenges, enabling continuous evolution: segregating medical device functions from platform functions to maintain agility without triggering full revalidation cycles.
This is part one of a three-part series on building software for regulated healthcare. Part two covers the architecture pattern that enables continuous evolution. Part three addresses change control and post-market sustainability.