Hardware Bible
Build a Medical Device from Scratch - The Book I Wish I Had Before My First Device
The brutally honest guide to medical device development that covers the entire journey from clinical need identification to post-market surveillance. Written by an engineer who's built 200+ medical devices over 8 years, this book addresses why 80% of medical device startups fail and provides practical frameworks for regulatory approval, manufacturing scale-up, and go-to-market strategies in healthcare's complex ecosystem.
1. Your book positions itself as a "brutally honest guide" to medical device development. In your view, what are the most overlooked truths that first-time founders must confront before even starting their journey?
Great technology loses to mediocre technology with smart business strategy every single time. The problem is that engineers think like engineers. They assume the best solution wins.
But in healthcare, purchasing decisions involve administrators worried about budgets, nurses concerned about workflow changes, procurement teams incentivized to cut costs, and committees that follow rigid evaluation processes.
Most founders also don't realize that getting FDA approval is just the beginning. You still need to figure out who's going to pay for your device, how to get it manufactured at scale, and why busy doctors should change their established routines for your product.
2. Having built 200+ devices, you've likely seen patterns of both success and failure. What recurring mistakes do you believe explain why medical device startups struggle?
The biggest killer? Companies fall in love with their solution before they understand the problem. I've seen this so many times. Someone has a cool sensor or algorithm, then they go hunting for a medical application.
Start with a real clinical problem that's actually worth solving - meaning it happens frequently, causes real harm, doesn't have good existing solutions, and someone will pay to fix it.
Regulatory strategy is another disaster area. Teams assume they can figure out FDA pathways later. Then they discover their device needs clinical trials they can't afford.
Manufacturing gets messy too. Your prototype works beautifully when your best engineer assembles it by hand. But production lines don't have your best engineer.
3. Clinical need identification is often described as the foundation of device innovation. How can entrepreneurs balance user-centered insights with technological feasibility and commercial viability at this early stage?
You need to think like a detective, not an inventor. Spend time in actual clinical environments. Watch what healthcare workers do when they think nobody's looking.
The most valuable insights come from observing workarounds. When you see nurses using tape and rubber bands to solve a recurring problem, you've found something worth investigating.
But here's where most people mess up: they stop at the first complaint they hear.
Keep digging!
Why does this problem exist? How often does it happen? What are people doing about it now? Who gets hurt when things go wrong?
The sweet spot is finding problems that score well across all three dimensions.
4. Regulatory pathways are one of the most intimidating barriers for startups. From your experience, what practical frameworks can streamline the FDA/CE approval process without compromising safety or quality?
Stop thinking about regulatory as something you do after development. It's something you design into your development process from the beginning.
First, figure out your device classification early. This determines everything - your timeline, evidence requirements, and budget. For 510(k) devices, pick your predicate device carefully because it shapes your entire submission strategy.
Build your quality system as you go, not after you're done. ISO 13485 is a systematic way to document that you made smart decisions and can prove your device works safely.
Here's a pro tip: run verification and validation activities in parallel with design development when possible.
5. Manufacturing scale-up is where many devices stumble. What are the critical inflection points where founders must shift their mindset from "prototype" to "production"?
The mindset shift happens when you realize that "making one that works" is completely different from "making thousands that work identically."
Your prototype probably depends on your best engineer making tiny adjustments during assembly. Production depends on written procedures that any trained technician can follow reliably. That transition is harder than it sounds.
Material sourcing often blindsides people. Your prototype supplier might not be able to handle production volumes. Or their manufacturing process changes slightly and suddenly your device performs differently.
I've seen this force expensive redesigns after regulatory submission.
6. In the book, you discuss post-market surveillance. How can startups strategically prepare for this phase instead of treating it as a regulatory afterthought?
Most companies think post-market surveillance is just complaint handling. If you're building connected devices, you can collect real-world performance data that traditional complaint systems never capture.
But even non-connected devices can benefit from systematic user feedback programs. The key is building relationships with your users that go beyond "call us if something breaks."
Regular check-ins, outcomes tracking, and user advisory programs provide genuine value while generating insights for product improvement.
Build surveillance capabilities during development. It's cheaper and more effective than trying to retrofit them later, and it often provides competitive differentiation through superior customer relationships.
7. Healthcare's ecosystem is layered with payers, providers, and regulators. What go-to-market strategies have you found most effective for navigating such complexity and accelerating adoption?
Forget the org chart. The real decision makers often aren't who you think they are. I learned this the hard way on an early project. We had surgeons championing our device, but couldn't get it adopted anywhere.
Turns out the head nurse for that department had quiet veto power over new products, and we'd completely ignored her workflow concerns.
Now I map stakeholder influence before any sales activity. Who actually uses the device? Who controls the budget? Who manages implementation? Who deals with problems when things go wrong?
Your value proposition needs to work for all of them. Hospital sales cycles are inherently long - often 6-18 months depending on complexity.
8. Could you share an example where a promising device failed - not because of design flaws, but due to missteps in commercialization or ecosystem alignment?
We had a cardiovascular monitoring device that genuinely outperformed everything on the market. Better accuracy, cleaner interface, improved clinical outcomes in trials. The technology was solid.
However, the business strategy had holes you could drive a truck through. First, nobody investigated reimbursement until after FDA clearance. Turns out the device didn't fit existing procedure codes well and required out-of-pocket payments from hospitals already operating on thin margins.
Second, the team focused entirely on physician champions and ignored the value analysis committees that actually controlled purchasing decisions.
The intellectual property eventually got sold to a larger company with established reimbursement relationships and distribution channels. Same technology, different commercialization approach - and it succeeded.
9. You emphasize frameworks rather than theory. Which specific framework from the book do you consider the most transformative for a struggling startup?
Risk-stratified validation changes everything for resource-constrained companies. Most startups treat validation like they're trying to prove their device is perfect. They apply the same level of testing to every component and feature, regardless of whether it could hurt someone or just affects user convenience.
That's expensive and stupid. Instead, categorize your device functions by risk level. Safety-critical functions that could harm patients get comprehensive validation with statistical rigor.
This typically cuts validation costs by 20-40% while improving regulatory submission quality.
For startups burning through runway, this approach often means the difference between reaching regulatory submission and running out of money during testing.
10. Medical device development increasingly overlaps with digital health and AI. How do your principles apply when software and hardware converge in regulated environments?
The fundamentals stay the same, but software adds complexity layers that catch people off guard. Risk management gets trickier because software can fail in subtle ways.
Your traditional failure analysis needs to include cybersecurity vulnerabilities, data corruption, algorithm bias, and integration problems with other systems.
Design controls for software require different approaches. You need cybersecurity assessment, user interface testing across different environments, and performance validation under various system loads.
Connected devices create both opportunities and headaches. You can collect amazing real-world usage data, but you also inherit privacy regulations and security requirements that standalone devices don't face.
Software integration needs to happen during design, not as an afterthought.
11. Given global disparities in healthcare access, how can device innovators adapt their frameworks to build solutions for low-resource or emerging markets?
I'll be honest - most of my experience is with US market development, so I can't speak authoritatively about the nuances of emerging market strategies. But the systematic approaches in "Hardware Bible: Build a Medical Device from Scratch" can be adapted, though priorities shift significantly.
Clinical need identification becomes more fundamental. You're looking for problems that cause serious morbidity where no alternatives exist, rather than incremental improvements to existing solutions.
Design constraints are completely different. Unreliable electricity, extreme temperatures, limited maintenance capabilities - these become primary design drivers rather than edge cases.
But I'd recommend partnering with people who have deep experience in your target markets.
12. Risk management is a recurring theme in medtech. From your engineering and entrepreneurial lens, how should startups structure risk analysis to satisfy both regulators and investors?
Think of risk management as translation between two languages. Regulators want to see systematic patient safety thinking. ISO 14971 provides the framework - systematic hazard identification, risk assessment, and mitigation strategies.
Investors want to understand business risks that could derail their investment. Market adoption challenges, competitive threats, regulatory approval uncertainties, technical feasibility questions.
The smart approach integrates these perspectives rather than treating them separately. Technical risks often affect both patient safety and commercial viability.
Be transparent about identified risks and mitigation strategies with both audiences. Update your risk assessments regularly as development progresses.
13. For engineers transitioning into founders, the leap from technical problem-solving to leadership is immense. How does your book prepare them for this mindset shift?
Engineering thinking actually transfers well to business problems - you just need to recognize that the variables and success metrics are different. Instead of optimizing algorithms, you're optimizing market adoption. Instead of debugging code, you're debugging commercialization barriers.
The biggest mindset shift is recognizing that technical excellence is necessary but not sufficient. Regulatory strategy, clinical evidence, manufacturing development, and commercialization often determine success more than technical superiority.
The hardest part is learning when to bring in specialized expertise rather than trying to master everything personally. "Hardware Bible: Build a Medical Device from Scratch" provides guidance on engaging regulatory consultants, manufacturing partners, and clinical advisors effectively.
14. Finally, looking ahead, what future trends - regulatory, technological, or market-driven - do you believe will redefine how medical devices are built and scaled over the next decade?
The technology convergence happening now is remarkable. Advanced sensors, miniaturization, connectivity, AI - all reaching maturity simultaneously. This lets smaller teams create sophisticated devices, but it also means your technology advantages don't last as long.
AI integration will probably focus on augmenting healthcare professionals rather than replacing them. Connected devices are becoming table stakes rather than differentiators.
The biggest shift is toward value-based development - aligning device capabilities with demonstrable health and economic outcomes rather than just technical specifications.
Future success will probably depend more on systematic business development and market understanding than pure technical innovation, though strong engineering remains the essential foundation.
