Ask HN: Why don't software developers make medical devices?
21 comments
What class of device are you talking about? Even if you clear FDA, commercialization is incredibly difficult. I think you're pish-poshing how hard it is to get regulatory clearance, btw. The regulatory approvals in US and ROW are incredibly difficult, costly, and time consuming to meet all the requirements imposed by the various regional authorities. Sounds like you are severely underestimating the costs, work and length of time to generate data and create an approval submission. You won't obtain labeling without funding and running clinical trials. It can take 5-10 years of development and clinical studies and $50-$100 million for PMA approval.
Then if you hit the market you are going up against the most connected, cutthrough, organized and entrenched sales forces from the large device companies who make tech b2b sales look like kindergarteners on the playground. The medical offices, site staff and hospitals all try to block access to your sales force so you are probably going to need to fund and deploy an MSL and RSL force as well and present at all the industry conferences to get any leads and traction.
Then even if you have customers who want your device it won't matter unless you develop a patient access team, lobby to secure reimbursement from insurers otherwise all your previous efforts are wasted. So now you need a market access team and you're probably $200 million in the hole, and you're dead in the water if CMS won't get onboard for reimbursement because all the private insurers generally wait and see what CMS does. Meanwhile any time any of your suppliers change you'll need to run more trials to show validation for safety and efficacy.
With average time to market is 12 years, 75% of new device companies fail for a reason.
Then if you hit the market you are going up against the most connected, cutthrough, organized and entrenched sales forces from the large device companies who make tech b2b sales look like kindergarteners on the playground. The medical offices, site staff and hospitals all try to block access to your sales force so you are probably going to need to fund and deploy an MSL and RSL force as well and present at all the industry conferences to get any leads and traction.
Then even if you have customers who want your device it won't matter unless you develop a patient access team, lobby to secure reimbursement from insurers otherwise all your previous efforts are wasted. So now you need a market access team and you're probably $200 million in the hole, and you're dead in the water if CMS won't get onboard for reimbursement because all the private insurers generally wait and see what CMS does. Meanwhile any time any of your suppliers change you'll need to run more trials to show validation for safety and efficacy.
With average time to market is 12 years, 75% of new device companies fail for a reason.
That is my point, though. You want something hard, something that requires actual money, effort, infrastructure, and lobbying. That in itself is the moat. As software developers, we have been lulled into this entirely unrealistic mode of thinking that extremely profitable products do not have to be expensive or high effort to bring to market.
That is exactly why vultures like LLM hustlers find their opening. There is a reason you do not see fly-by-night LLM hucksters selling medical insurance or devices, not because they cannot do the job of building the thing itself, but because the surrounding moat is too high for them to clear.
That is exactly why vultures like LLM hustlers find their opening. There is a reason you do not see fly-by-night LLM hucksters selling medical insurance or devices, not because they cannot do the job of building the thing itself, but because the surrounding moat is too high for them to clear.
You’re defining a hustler as someone who can’t manage a small company or who is unwilling to do extroverted or operational tasks. I don’t think that’s helpful because there are plenty of hustlers oriented around those tasks, who now also can advance the software side and a lot of the paperwork with a smaller team, perhaps even with a semi-technical team or cofounder. The existence of these people means that to me, a person comfortable with thorny operations, marketing, and compliance issues, the existence of lazy vibe coders don’t affect my estimate of profitability of a medical device startup.
Since I have no idea about the topic I've asked an llm: "could you make a list of useful medical devices that are possible to make but not on the market?"
A lot of entries suggested cheaper versions of existing devices. For less wealthy markets, for prevention, to bring diagnosis closer to the incident and for real time monitoring.
I imagine getting a device approved in a different country might create runway to scale to the domestic market?
A lot of entries suggested cheaper versions of existing devices. For less wealthy markets, for prevention, to bring diagnosis closer to the incident and for real time monitoring.
I imagine getting a device approved in a different country might create runway to scale to the domestic market?
Because just like in the legal profession, finance and the defense industry, medicine is a heavily regulated and protected field (as it should) which is meant to gatekeep against low quality or harmful "medical" devices that could be built by anyone.
The costs itself to enter already makes it close to impossible without outside funding which is why you see less startups in this and more vibe-coded toys that are at best experiments.
No-one would be happy to hear that they are using a "vibe coded" medical device instead of the established solutions.
The costs itself to enter already makes it close to impossible without outside funding which is why you see less startups in this and more vibe-coded toys that are at best experiments.
No-one would be happy to hear that they are using a "vibe coded" medical device instead of the established solutions.
I am talking about class 2 medical devices. It takes you maybe $200k at the high end to clear FDA and trials. High enough that all these bottom feeder LLM providers will drop out but low enough small burners can thrive.
There are two enemies. Chinese manufacturers who will dump a cheaper alternative the second you find success. With FDA and trials gates, they are out. The second is LLM guys who sit in the middle vulture state. They are ok with violating every law, every established norm except industries that are more powerful than them: healthcare and banking.
By forcing them to invest at minimum $200k-250k per product, they will be a lot more hesitant. It is easier to violate some poor author's copyright, but in this case each time they try to compete with you they have to jump this high gate.
I am not saying this is easy money. There are established corps already looking to expand their business, but $10M-15M won't move the needle for them, and for those it does, you can compete.
There are two enemies. Chinese manufacturers who will dump a cheaper alternative the second you find success. With FDA and trials gates, they are out. The second is LLM guys who sit in the middle vulture state. They are ok with violating every law, every established norm except industries that are more powerful than them: healthcare and banking.
By forcing them to invest at minimum $200k-250k per product, they will be a lot more hesitant. It is easier to violate some poor author's copyright, but in this case each time they try to compete with you they have to jump this high gate.
I am not saying this is easy money. There are established corps already looking to expand their business, but $10M-15M won't move the needle for them, and for those it does, you can compete.
I work in this field, and I've never seen a device that isn't dead simple be able to clear the FDA for $200k. I've definitely never seen a medical device with software anywhere near this.
The reason people don't switch to medical devices is because even a fairly simple device without software or electronics can still take between $750k and $1.2M to develop and clear the FDA. Adding software is a cost & time multiplier.
The reason people don't switch to medical devices is because even a fairly simple device without software or electronics can still take between $750k and $1.2M to develop and clear the FDA. Adding software is a cost & time multiplier.
I think it is protected by many moats. Personally I don't mind building and using devices by and for myself, but to commercialize them? It's going to be a huge headache, and you can bet that many companies sit on the moats for their lunch. You and I will never know which of the moats really make sense and which ones are simply BS for barriers. It's too much hassle.
That is what you want. The harder and more difficult the moat, the higher the gate for these bottom-feeder product dumpers to clear. Once you clear that yourself, you would be in the promised land.
It is hard, it is expensive, and there is a lot of work, but anything worth $10M in yearly profit is. You want to avoid any product that a Chinese manufacturer can pump and dump on Amazon almost immediately, if Amazon itself doesn't, or a product an Indian teenager can create in a few hours thanks to LLMs and compete with. You want those paths to be impossible for them to clear.
It is hard, it is expensive, and there is a lot of work, but anything worth $10M in yearly profit is. You want to avoid any product that a Chinese manufacturer can pump and dump on Amazon almost immediately, if Amazon itself doesn't, or a product an Indian teenager can create in a few hours thanks to LLMs and compete with. You want those paths to be impossible for them to clear.
"The medical devices I'm talking about require around $50K–$200K for FDA clearance"
I think that's only if you use the expedited approval process (510k).
I actually had an idea for a medical device. Turns out there was a patent on that idea already. It wasn't on the market yet. The potential client population wasn't very big, but just big enough to make it worth while.
I think that's only if you use the expedited approval process (510k).
I actually had an idea for a medical device. Turns out there was a patent on that idea already. It wasn't on the market yet. The potential client population wasn't very big, but just big enough to make it worth while.
Are you saying even if I stretch the budget to $500k, there isn't a niche where I can find viable device?
No, but it seems unlikely given all the other failed companies/devices.
They do but the industry and regulations are such that this is usually led by people who have medical degrees or, say, phds in relevant fields. A "software guy" can then be up to VP level and lead the software aspect. This makes a lot of sense considering the credibility and expert knowledge required.
Such folk (medical degrees; phd's) are notoriously hard to pin down and finish a product. Been part of more than one; after years of unfocussed effort they failed to deliver.
There's a nice middle ground here, Software as a Medical Device (SaMD) which also goes through 510(k) in the US and has its own regulatory pathways distinct from hardware medical devices
How did you get into this field to begin with? Would definitely be interested in switching into a field like this
Because hardware is very different from software, one does not just switch like that
Is this the new “why don’t coal miners just learn how to code?”
Because the development process requires Functional Safety and most regular programmers will struggle with the glacial progress that occurs under such regimes.
While IEC 61508 is the parent of all Functional Safety, medical devices are a little divorced form 61508 and have their own primary standard IEC 60601.
Some good explanation occurs here https://blog.johner-institute.com/systems-engineering/functi....
But this is the sort of engineering where you know everything about what your functionality will be, and what code and what type of code will be used to achieve it, well before you even think about starting to code.
The testing requirements can include things like testing every possible combination of inputs, for every possible combination of states (often just not practical, but there are some techniques to say, we will ignore these combinations etc). Every part of the final code shall be traceable back to a requirement so on and so on.
In industrial Functional Safety you might very easily work on requirements and definition for 2 years before you even think about what you might code, or even the device or platform you might be coding on.
I know of a mine winder job (Could kill 100 people in one go, so sort of like a passenger jet in risk profile) where the defining aspect of the design/build/commissioning critical path was Functional Safety, and it ran 10 years from very beginning to in service.
Imagine the most painful and anal waterfall process you could possibly dream of, and it is more onerous than this, plus you are exposed to being kicked backed to an earlier phase if certain problems are discovered.
If you are a move fast and break things, Mondays is pivot day and we like to actually roll some dice to decide what this weeks pivot will be, type of guy/gal, you are likely totally mentally not ready for how this needs to work, and probably don't want to be.
Plus if you come from a world where everything is a listener, and various other event driven paradigms, most of these people real struggle with real time highly deterministic systems.
This is because these invariably end up needing to be scanned logic, which looks stupid coming from this background. But, it is the best way that you can assure repeatable defined behavior, because event driven code is almost always of the type that ends up with an arbitrary order of execution, and this is not suitable for systems that have expectations of a highly deterministic nature.
There are zero cases for such devices where the answer to a problem is "just send that email again", to show the wagon wheel and/or drop a few frames or show some at lower resolution, or tell the user "just reboot at intervals of no more than 23 days and hold down the reset button while you boot", and so on.
And, some of these devices can do firmware upgrades OTA (not actually very common for somewhat obvious reasons), some need a special programming device within very close proximity and/or wired, and some are made with code in factory silicon and if you get it too wrong you recall them all for binning, at great expense.
I see another comment says that time to market for medical devices averages 12 years, and 75% of companies formed to make these devices fail - yeah I can totally see that, especially if it is a device that might roll out in the thousands to hundreds of thousands, the potential for harm, and for that harm to arise from software that either is specified poorly, or implemented poorly, is very large, extremely large.
I am a functional safety engineer, for well over ten years now, mostly industrial process and machinery, I hold certs from TUV Rhineland SIS and Certified Machinery Safety Expert TUV Nord.
But these are like one week courses, almost anyone that can pay attention could usually pass, though you need grades like 80% or 65% etc depending who runs the course you do.
More importantly (and written quite heavily into the standards) is you need to be competent, in the formal sense, which only comes from working with, or under, other engineers with suitable experience and background, and this might realistically be minimum 5 years, certainly no less than 3.
So moving into real time, embedded often, limited memory and CPU resources, need to know RF maybe as well, on it goes, do you as a well paid dev engineer want to go back to close to square 1 for x years, working in a way that will probably at best seem very antiquated to you, though most requirements are for good reasons when you understand them.
And ultimately, similar to other Fields of Functional Safety, the coding and all the computer stuff is probably easier learned by someone with extensive domain experience,
This is opposed to being an experienced coder (in most likely a different kind of code) and acquiring anywhere near the same domain experience in any reasonable time. eg in this case you are probably much more likely to to find medical people with training and experience that fell into dev roles to service the need, and it might be very difficult to compete with them, for what might be both real and perceived/cultural/"club" reasons.
There is more, but I am sure that is enough in the immediate context - not trying to be discouraging, just realistic.
While IEC 61508 is the parent of all Functional Safety, medical devices are a little divorced form 61508 and have their own primary standard IEC 60601.
Some good explanation occurs here https://blog.johner-institute.com/systems-engineering/functi....
But this is the sort of engineering where you know everything about what your functionality will be, and what code and what type of code will be used to achieve it, well before you even think about starting to code.
The testing requirements can include things like testing every possible combination of inputs, for every possible combination of states (often just not practical, but there are some techniques to say, we will ignore these combinations etc). Every part of the final code shall be traceable back to a requirement so on and so on.
In industrial Functional Safety you might very easily work on requirements and definition for 2 years before you even think about what you might code, or even the device or platform you might be coding on.
I know of a mine winder job (Could kill 100 people in one go, so sort of like a passenger jet in risk profile) where the defining aspect of the design/build/commissioning critical path was Functional Safety, and it ran 10 years from very beginning to in service.
Imagine the most painful and anal waterfall process you could possibly dream of, and it is more onerous than this, plus you are exposed to being kicked backed to an earlier phase if certain problems are discovered.
If you are a move fast and break things, Mondays is pivot day and we like to actually roll some dice to decide what this weeks pivot will be, type of guy/gal, you are likely totally mentally not ready for how this needs to work, and probably don't want to be.
Plus if you come from a world where everything is a listener, and various other event driven paradigms, most of these people real struggle with real time highly deterministic systems.
This is because these invariably end up needing to be scanned logic, which looks stupid coming from this background. But, it is the best way that you can assure repeatable defined behavior, because event driven code is almost always of the type that ends up with an arbitrary order of execution, and this is not suitable for systems that have expectations of a highly deterministic nature.
There are zero cases for such devices where the answer to a problem is "just send that email again", to show the wagon wheel and/or drop a few frames or show some at lower resolution, or tell the user "just reboot at intervals of no more than 23 days and hold down the reset button while you boot", and so on.
And, some of these devices can do firmware upgrades OTA (not actually very common for somewhat obvious reasons), some need a special programming device within very close proximity and/or wired, and some are made with code in factory silicon and if you get it too wrong you recall them all for binning, at great expense.
I see another comment says that time to market for medical devices averages 12 years, and 75% of companies formed to make these devices fail - yeah I can totally see that, especially if it is a device that might roll out in the thousands to hundreds of thousands, the potential for harm, and for that harm to arise from software that either is specified poorly, or implemented poorly, is very large, extremely large.
I am a functional safety engineer, for well over ten years now, mostly industrial process and machinery, I hold certs from TUV Rhineland SIS and Certified Machinery Safety Expert TUV Nord.
But these are like one week courses, almost anyone that can pay attention could usually pass, though you need grades like 80% or 65% etc depending who runs the course you do.
More importantly (and written quite heavily into the standards) is you need to be competent, in the formal sense, which only comes from working with, or under, other engineers with suitable experience and background, and this might realistically be minimum 5 years, certainly no less than 3.
So moving into real time, embedded often, limited memory and CPU resources, need to know RF maybe as well, on it goes, do you as a well paid dev engineer want to go back to close to square 1 for x years, working in a way that will probably at best seem very antiquated to you, though most requirements are for good reasons when you understand them.
And ultimately, similar to other Fields of Functional Safety, the coding and all the computer stuff is probably easier learned by someone with extensive domain experience,
This is opposed to being an experienced coder (in most likely a different kind of code) and acquiring anywhere near the same domain experience in any reasonable time. eg in this case you are probably much more likely to to find medical people with training and experience that fell into dev roles to service the need, and it might be very difficult to compete with them, for what might be both real and perceived/cultural/"club" reasons.
There is more, but I am sure that is enough in the immediate context - not trying to be discouraging, just realistic.
1. Natural Moat
Since human body hardware is more or less immutable in its most essential parts, you don't have to worry about some LLM hype cycle replacing you. Once you build the product and clear FDA or local certifications, you're set. Unlike Uber destroying the taxi medallion business, healthcare is a beast — no tech startup dares to bypass all the regulations and gatekeeping.
2. Regulatory Moat
The medical devices I'm talking about require around $50K–$200K for FDA clearance — low enough that any small business can manage it, but high enough to discourage bottom-feeders and Chinese product dumpers. It also lets you avoid the big established healthcare corporations, because this market segment is too small for them to care about, yet large enough for you to pull in $10M–$15M a year in revenue.
Medical device manufacturing sidesteps the two fatal flaws of software development: the lack of a moat and static, almost never-changing hardware margins. LLM companies don't care about copyright, IP, or the health of the broader economy — but they can't go head-to-head with the healthcare industry, so you don't have to worry about them at all.