Marrying Software and Hardware: The Pressures and Pain Points of Building a Software-Driven Medical Device

 In Industrial Design, Medical Product Design

Medical devices are increasingly built around software. Of course, almost any medical device with a battery or power cord has a software component of some kind. But as more and more tech companies enter the medical space, the role of software in medical devices is changing. Today, it’s more common than ever for software to comprise a medical device’s core offering.

In fact, the FDA now recognizes some software as a medical device all on its own, without any physical components involved.

The rise of software-centered medical devices means many medical tech companies must now work closely with hardware engineers, sometimes for the first time.

It’s natural for software companies to see the physical components of a device as somehow less valuable or deserving of less attention. But if you slap together the hardware that houses your software offering, you risk creating a product that doesn’t fit your users’ needs. Worse still, poorly designed hardware can sometimes even interfere with the software’s functioning and lead to a faulty product.

The success of even the most software-driven medical device ultimately depends on how well the software and hardware function together as a cohesive product that achieves clinical outcomes and meets user needs. Hardware that is suited for software makes programming easier, which makes the device more energy efficient and more robust.

Hardware isn’t a burdensome necessity. It’s an opportunity to add value. But it takes time, resources, and expertise to get it right.

Medical tech companies often make the assumption that hardware engineering is as agile, iterative, and fast-paced as software development. It’s not. Here’s what you need to know.

Software Development vs. Hardware Engineering for Medical Devices: Key Differences

Hardware engineering differs from software development in pretty significant ways. This is because hardware engineers must translate their designs into physical form, a process that is both time-consuming and costly. Understanding the key differences between software and hardware development will help you set appropriate expectations. And it will also help you think realistically about how hardware development will impact your medical device’s overall budget and production timeline.

Design Iterations

Both software developers and hardware engineers begin with initial designs and iterate on them as they build toward a production-ready end product. For software developers, the iterative process is rapid and agile. Their work can be rendered nearly instantaneously into a functioning prototype that can then be further iterated on as soon as they are ready to make additional changes. A software developer’s ability to adjust her work on the fly is what makes it truly agile.

Hardware development iterations, on the other hand, take the form of much longer cycles. Each design iteration must be translated into a physical prototype before it can be further reprised. Physical prototype production can take weeks or months, depending on the complexity of the product and the fidelity of the prototype.

Because working prototypes take so long to produce, hardware engineers must approach product development differently than their software counterparts. Hardware engineers must be more calculating and less agile in their development process (which typically follows the waterfall methodology). They must have a higher degree of confidence that their next round of design changes represents a step in the right direction. This is especially true right now with the current international supply chain shortages. There are simply less hardware options.

For hardware engineers, wrong moves simply take more time to remedy. And they cost more money, too.

That’s because hardware development iterations are much more expensive than software iterations. The cost of producing physical prototypes is always higher than that of the manufactured end product — sometimes shockingly so. And, as the fidelity of the prototype grows, so does the price tag.

Verification Testing

Hardware engineers and software developers both use testing to verify that their products have actually been built according to spec. Software engineers often use A/B testing to try out more than one solution. Verification testing for software represents an important investment of time and resources, to be sure. But the cost and time required to verify hardware is much greater. This is especially true for medical devices, which almost always have to be developed under Design Controls to prove to the FDA that they are safe and clinically effective.


So what does verification testing for hardware look like? Medical device engineers must test and successfully verify each design requirement in a lab setting on a prototype with near-production-level tooling. It all begins with the verification protocol. A verification protocol is a full, documented plan dictating how a team will verify each design requirement. This includes exactly how the product will be tested, what the lab setup will look like, how many test cycles will be completed, and so on. For example, if a product is designed to bear a certain amount of weight, the verification tests must prove that it is capable of bearing at least that amount of weight over the course of normal, repeated use.

Hardware testing can take a long time. Simply putting together a verification protocol is a lot of work. The lab must then be prepared for testing, and the tests must then be administered. In the event of cycle tests, it may take several weeks to complete a single test (for example, a test in which a device must run through a million cycles without breaking).

If the device fails a test, the engineering team must go back to the drawing board. Only once a particular design passes verification testing can the device move forward to the next stage of development.

Finally, hardware engineers rarely use A/B testing. The cost of producing multiple physical prototypes for comparison’s sake is just too high.


Software developers functionally skip the manufacturing stage of product development (or, perhaps more accurately, software development is a form of manufacturing). These days, most software products live in the cloud; there’s no physical component to manufacture or distribute. But for hardware engineers, manufacturing represents yet another costly and time-consuming phase of production.

At a very high level, manufacturing includes the following steps:

  • Materials selection. This is a large undertaking with many possible considerations which might include bio-compatibility, cost, user preferences, chemical resistance, and durability for use cycles.

  • Tooling. Tooling refers to the physical device and things like injection molds that will be used to manufacture a medical device. Tooling is extremely expensive and very time consuming.

  • Testing and verification of parts. Newly tooled parts must be analyzed and/or tested to verify that they meet the design specifications within a very tight range of acceptability before the device can go into production.

Each of these stages takes time, money, and expertise to execute.


Software developers are accustomed to pushing out updates and bug fixes on a very rapid cadence. In the case of apps, updates may be pushed out as frequently as every two weeks.

Manufactured products can’t be instantly updated. It takes time and money to correct a design flaw or introduce a new update. And, in most cases, companies must sell through existing stock before they can invest in a new design. If a medical device goes to market with a major flaw, there are typically three options. The first is to allow your subpar design to ride out in the market unchanged.  The second is to make incremental changes as a sustaining effort to improve future product in the next manufacturing cycle. The third (more serious) option is to issue a recall or substantial redesign. Each option represent lost opportunity. In the case of recalls and redesigns, market absence and redevelopment costs are major downsides.

The bottom line? Hardware engineers are under much greater pressure to get a device’s design right the first time.

For software-driven medical devices, software and hardware are really two sides of the same coin. Both have the ability to make or break your product. Understanding the ways that software development and hardware engineering differ will help your team chart a realistic course for your medical device’s development — and make the necessary investment in hardware engineering, too.


Recent Posts