For every MedTech development program, building a working prototype is an important milestone. It proves that a core technology, mechanism, algorithm, or clinical concept has the potential for success. But a prototype is not a commercial medical device, and treating it as one can create one of the most expensive mistakes in product development.

Early prototypes are intentionally optimized for speed and learning. Engineers may use 3D printed parts, machined components, temporary fixtures, oversized power supplies, manual calibration, laboratory software, or components selected because they are immediately available. Those choices can be exactly right for answering an early technical question. The problem begins when temporary prototype decisions are allowed to become permanent product architecture without being reevaluated against commercial requirements.

The transition from prototype to product requires a different mindset. The objective is no longer simply proving that the technology can work. The organization must demonstrate that the product can be manufactured repeatedly, meet cost targets, satisfy regulatory requirements, withstand verification and validation, support clinical users, survive its intended life and be serviced and supplied at commercial scale. Planning for that transition early is what helps prevent the prototype from becoming a technical dead end.

Proof of Concept vs. Product Architecture: Knowing When to Rebuild

A proof of concept should answer specific questions. Can the sensing technology achieve the required performance? Can the mechanism produce the necessary force or motion? Can the algorithm detect the intended signal? Can the clinical workflow be demonstrated? Once those questions have been answered, the development team should intentionally decide which portions of the prototype can move forward and which need to be re-architected.

This decision is critical because prototype architectures often contain assumptions that are incompatible with commercialization. Components may be too large, too expensive, nearing obsolescence, difficult to source, or unavailable in production quantities. Software may lack the structure, documentation, testability, cybersecurity controls, or error handling required for a released medical product. Mechanical assemblies may work when carefully adjusted by an engineer but be unsuitable for repeatable manufacturing.

Rather than asking, ‘How do we turn this prototype into the product?’ development teams should ask, ‘What did this prototype teach us, and what architecture should the commercial product now require?’ That distinction allows the organization to preserve validated learning without becoming trapped by implementation decisions that were never intended for production.

Establishing the commercial architecture at the right point also creates the foundation for requirements, risk management, design reviews, supplier engagement, verification planning and design transfer. Delaying that transition may make the program appear to move faster initially, but it often shifts risk and cost into later phases when changes are significantly more disruptive.

Design for Manufacturing and Assembly: Building Repeatability Into the Product

A prototype only needs to be built successfully a small number of times. A commercial product must be built successfully over and over again by people who were not part of the original development team. That difference changes how mechanical assemblies, electrical systems, calibration processes, test methods, tolerances, fastening strategies and component selections should be designed.

Design for Manufacturing and Assembly should begin while the architecture is still flexible. Engineers should evaluate how parts will be fabricated, assembled, inspected, calibrated, tested, packaged and serviced. Features that require difficult alignment, manual adjustment, excessive fasteners, tight tolerances, or highly specialized assembly techniques may increase cost and reduce manufacturing yield even when they perform well in a prototype.

Consulting partners and manufacturers can provide valuable input during this phase. Engaging them before the design is frozen helps identify tooling constraints, process capabilities, COGS, material limitations, lead times, test requirements, and opportunities to simplify assembly. The goal is not to hand an unfinished design to manufacturing, but to incorporate manufacturing knowledge into engineering decisions before those decisions become expensive to change.

Production test strategy should also be considered during development. A commercial product needs a practical way to confirm that each manufactured unit performs correctly. Designing test access, calibration features, diagnostic capability and automated test opportunities into the product can substantially improve production efficiency and traceability.

Supply Chain and Cost of Goods: Engineering the Business Case

A technically successful medical device can still fail commercially if it cannot be produced at the required cost or if critical components cannot be sourced reliably. Component availability, supplier concentration, minimum order quantities, tooling investment, lead times and lifecycle status should therefore be treated as engineering inputs rather than purchasing issues addressed after design completion.

Cost of Goods should be estimated and refined as the product architecture matures. Early estimates do not need to be perfect, but they should be detailed enough to identify the major cost drivers and determine whether the design is moving toward the commercial target. Waiting until design transfer to discover that the product costs twice as much as the business model allows can force major redesign at the worst possible time.

The same discipline applies to supply chain resilience. Single-source components may sometimes be unavoidable, but their risk should be understood. Teams should evaluate alternates where practical, monitor component lifecycle status, and consider how a substitution would affect software, electrical performance, biocompatibility, sterilization, mechanical fit, verification, or regulatory documentation.

The objective is not simply to reduce cost. It is to create a product architecture that balances performance, quality, supply continuity, manufacturability, and commercial economics.

Requirements, Risk Management, and V&V: Creating Objective Evidence

Prototype development is often driven by experimentation. Commercial development requires that those experiments evolve into controlled requirements and objective evidence. The team must define what the product is expected to do, the conditions under which it must perform, the risks associated with failure, and how successful performance will be verified.

Clear requirements become the backbone of the development program. They should address system performance, mechanical and electrical functionality, software behavior, environmental conditions, usability, reliability, manufacturing needs, service requirements and applicable safety constraints. Those requirements should remain traceable to risk controls and eventually to Verification and Validation activities.

This discipline is especially important when a prototype has already generated excitement. Demonstrations can create confidence that the product is further along than the development evidence actually supports. A device performing successfully in a controlled demonstration does not establish tolerance to environmental variation, component variation, repeated use, foreseeable misuse, transportation, cleaning, network interruptions, power conditions, or other scenarios relevant to the intended product.

Building the requirements and verification strategy while the design is still evolving allows the team to identify gaps before formal testing begins. Discovering that a requirement is untestable or that a risk control cannot be objectively verified after verification units have already been built can introduce avoidable schedule delays and redesign.

Reliability, Serviceability, and the Real World

Prototypes typically live protected lives. Engineers handle them carefully, know their limitations, recognize abnormal behavior, and can repair them when something goes wrong. Commercial medical devices do not have that luxury. They are transported, cleaned, dropped, powered on and off, updated, stored, serviced and used by people who were never involved in their development.

Reliability engineering should therefore address the stresses the product will experience throughout its intended life. Depending on the device, this may include repeated mechanical cycling, battery aging, connector wear, fluid exposure, temperature and humidity, transportation, cleaning and disinfection, software uptime, sensor drift, and component degradation.

Serviceability should also be considered as part of the architecture. Development teams should define what can be diagnosed remotely, what requires field service, what components can be replaced, how calibration is maintained, how service events are documented, and how the device can be returned to a known safe state. These decisions influence enclosure design, software diagnostics, component access, training, cost, and customer experience.

Designing for the real world does not mean anticipating every possible failure. It means systematically understanding the intended environment and creating an architecture that can tolerate expected variation while making abnormal conditions visible and manageable.

The Bottom Line

A working prototype proves that an idea can work. Commercial product development proves that the idea can become a medical device that can be manufactured, verified, validated, supplied, serviced and used reliably in the real world.

Each activity builds upon the one before it. The prototype establishes technical feasibility. Commercial architecture converts learning into a product foundation. Design for Manufacturing and Assembly creates repeatability. Supply chain and cost planning support the business case. Requirements and risk management define what success means. Verification and Validation provide objective evidence, while reliability and service planning prepare the product for life beyond the development laboratory.

Organizations that recognize this transition early can use prototypes for what they do best: reducing uncertainty and accelerating learning. The goal is not to eliminate iteration or make an early prototype look production-ready. It is to make deliberate engineering decisions about when experimentation ends and commercial development begins. Throughout every phase of development, maintaining that distinction helps prevent short-term prototype shortcuts from becoming long-term commercialization barriers and creates a more predictable path from concept to market.

If you’d like to discuss the MedTech development program or learn more about building a successful prototype, please connect with a MIDI subject matter expert at: