Ask HN: Why don't software developers make medical devices?
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.
17 comments
[ 2.8 ms ] story [ 63.8 ms ] threadThen 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 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.
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 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.
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 ...
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?