Why The Next Wave Of Medtech Startups Won't Build Their Own Hardware
Aaron Timm is the CEO of Openwater.
gettyProprietary hardware was once nearly the only pathway to building a new medical device company. Every founding team faced a familiar sequence: invent the physics, build the factory, write the code and fund multiple rounds of testing and clinical trials. Today, complex devices that require extensive clinical evidence and a credible reimbursement story can easily consume nine-figure budgets and a decade or more of effort.
That timeline was manageable when the broader development environment held relatively still. For decades, the standard playbook started with European CE marking and used that approval as a foundation for eventual FDA clearance. Recent changes to CE marking requirements have inverted that sequence for many new devices, making FDA clearance the first and often only near-term regulatory target. Founders who assumed they could stage their regulatory risk across two jurisdictions are now facing a single, more demanding starting gate, with more capital tied up in clinical evidence earlier in the life cycle and less available for experimentation.
Open-source hardware is changing what’s possible within those constraints. Building on an existing, technically validated hardware foundation rather than developing proprietary hardware from scratch lets founders redirect capital toward the work that most directly determines whether a device reaches patients: clinical evidence, reimbursement strategy and health system adoption.
Open-source medical devices are not a new concept, but most of the early success stories have been in software rather than hardware. A prime example is automated insulin delivery (AID) systems that combine insulin pumps with glucose monitoring and sophisticated algorithms to automate blood glucose control for people with diabetes.
While several companies have produced proprietary AID devices, what’s notable is the way grassroots patient communities drove the development of open-source alternatives, generating a body of real-world evidence that institutional researchers and commercial developers could later build on. Tidepool’s FDA clearance for the first open-source AID system showed the underlying dynamic: Once an open platform accumulates clinical evidence through academic and institutional use, later organizations pursuing clearance can build their regulatory submissions on that foundation instead of funding every study from scratch.
The question that arises is whether the same logic can extend to hardware. In the diabetes example, the algorithms uniting the pumps, sensors and delivery mechanisms were the open foundation, while the hardware was supplied by established manufacturers with their own regulatory histories. With open‑source hardware, the entire stack, including the circuitry, mechanics and firmware, is open to inspection, validation and modification in ways that a licensed proprietary platform is not. For a founder, that means starting from a design that already has technical and regulatory history, rather than treating hardware as a greenfield R&D program.
Neurotech is one medical field that is already seeing greater interest in open-source hardware. Platforms like OpenBCI provide open-source biosensing PCBs and CAD files that have allowed hundreds of academic labs to publish peer-reviewed central nervous system data without building hardware from scratch. Similarly, in the acoustic space, the EchOpen initiative has demonstrated that ultrasound hardware architecture can be open sourced via public circuit designs and firmware. Even the NIH has stepped in, funding the COSMIIC Project to create open-source hardware and regulatory documentation blueprints specifically for neuromodulation devices.
For founders, being able to review the design files and compliance documentation up front creates unprecedented transparency about technical and regulatory risk. Open-source platforms attract academic and institutional researchers for the same reasons, generating a body of peer-reviewed clinical and technical evidence (such as this clinical trial of transcranial focused ultrasound for depression, supported by an Openwater investigator-initiated grant) that exists before a commercial entity arrives. The regulatory submission can start from a foundation informed by documented use history rather than a blank page, and the capital that would otherwise go toward establishing that history is available for ensuring a cleared device finds its market.
Open-source hardware will scale in medtech only if companies can turn shared designs into controlled, commercial products. The key regulatory question is whether the company bringing a device to market can demonstrate control over the specific configuration it manufactures and supports. That company remains responsible for its intended use, risk management, verification and validation, clinical evidence, manufacturing process, and postmarket obligations.
Manufacturing and quality systems are central to the model, since an open design file is a technical starting point, not a finished production process. A founder still has to turn that design into a controlled product, with qualified suppliers, documented design changes and a manufacturing process that produces the same result every time.
Licensing matters, too. Before choosing an open platform, companies need to understand whether they can commercialize and modify the technology, pursue patents and, where appropriate, keep their own improvements proprietary. The most useful platforms will make that possible through clear governance, maintained documentation and reliable version control.
As those pieces come together, adoption by health systems, investors and physicians is more likely to follow. Open platforms will earn confidence through the same fundamentals that support any medical technology: transparent technical documentation, credible institutional use, a growing evidence base and a clear, accountable path from design to commercial product.
Founders do not have to treat open-source technology as an all-or-nothing decision. The practical question is which parts of the system are truly central to the company’s advantage. Hardware or firmware that has already been used and studied in academic or institutional settings can be a sensible place to start, particularly when there is published technical evidence and an experienced user community behind it. The company still has to validate and control the final product it sells. But it can focus its proprietary work on the clinical application, workflow, data, manufacturing know-how or other elements that make its offering meaningfully different.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
