Medical-device programs rarely fail because one discipline lacks effort. More often, the team advances a promising design while product definition, risk, interfaces, evidence or manufacturing assumptions remain unresolved. The cost appears later as redesign, unusable test data, submission questions or transfer problems.
The following mistakes are preventable. Each one can be turned into an explicit technical decision and evidence plan.
1. Freezing the solution before defining the intended use
A prototype can make the product feel more mature than its definition. Intended use, indications, users, patients, use environment, operating principle and claims influence device classification, risk controls, human factors and the evidence required to market the device.
Write the product definition before committing to a detailed architecture. Track open assumptions. FDA explains in How to Study and Market Your Device that classification and applicable regulatory controls are tied to device risk and intended use.
2. Treating regulatory strategy as a late documentation task
A submission pathway is not a label applied after testing. Classification, predicates, special controls, recognized standards and planned claims can change the architecture and evidence plan. A device with a novel technology or indication may need different evidence from a superficially similar product.
Complete early product-code and pathway research. Identify questions that could change development. The FDA’s Q-Submission Program provides voluntary routes for obtaining feedback on focused questions before a future submission.
3. Building risk files after the design is mostly complete
Risk management should shape the product. Retrofitting a hazard analysis often produces weak controls such as warnings or procedural checks because the architecture can no longer change economically.
Use the risk process to derive design inputs, assign controls and define verification. Continue it through production and post-production information. ISO 14971:2019, confirmed current by ISO in 2025, covers medical-device risk management across the lifecycle.
For a motor-driven device, for example, unintended motion can require mechanical stops, current limits, position plausibility, safe-state logic, independent shutdown paths, user-interface behavior and fault-injection tests. The control set is system-wide.
4. Writing requirements that cannot be verified
Words such as accurate, intuitive, lightweight, reliable and fast do not define an acceptance condition. They hide disagreement until formal testing.
State the observable behavior, conditions and limit. Identify units, range, tolerance, environment, load, timing, sample, configuration and any relevant statistical basis. Link the input to its source and planned method. If the method cannot be described, the input needs more work.
5. Letting interface assumptions remain inside disciplines
Subsystems can pass their own tests while the integrated product fails. Common gaps include sensor range versus algorithm assumptions, connector pinout versus grounding, mechanical tolerance versus optical calibration, software timing versus actuator dynamics, and enclosure design versus power-stage cooling.
Create controlled interface definitions. Review data ownership, timing, coordinate frames, tolerance stacks, power budgets, fault behavior, calibration dependencies and physical constraints across disciplines. Assign one system owner to resolve contradictions.
6. Testing an unknown or moving configuration
A result without a controlled configuration is difficult to reproduce and may not support a formal conclusion. Prototype teams often change firmware, components, fixtures or calibration settings during a test campaign without recording the impact.
Baseline hardware, software, programmable logic, calibration, accessories, fixtures, procedures and environments before verification. Preserve deviations and failures. When a change occurs, decide which results remain valid and which need repetition.
7. Confusing verification with validation
Verification demonstrates that design outputs meet design inputs. Validation demonstrates that the resulting device meets user needs and intended uses under actual or simulated use conditions. A design can satisfy its written specifications and still be unsuitable or unsafe for the intended workflow.
Plan both evidence streams early. Use production units or justified equivalents for validation. Include representative users and environments where applicable. FDA’s August 2026 human-factors guidance emphasizes interactions among users, uses, use environments and interfaces.
8. Delaying manufacturing involvement until transfer
A hand-built prototype can rely on rework, expert judgment, adjustable fixtures and selected components. Production needs controlled materials, tolerances, assembly methods, inspection, calibration, software loading, test coverage and traceability.
Involve manufacturing and suppliers while architecture and tolerances can still change. Build production-intent units. Evaluate whether processes are capable and whether inspection can detect characteristics essential to safety and performance. Where results cannot be fully verified later, determine whether process validation is needed.
9. Assuming software and cybersecurity can be added at the end
Software architecture, fault handling and security influence hardware resources, communications, service tools and update mechanisms. Late security additions can conflict with usability, real-time behavior and field support.
Define software safety functions, states, interfaces, logging, error handling, configuration and test strategy early. For connected devices, include threat modeling, authentication, authorization, data protection, update behavior and vulnerability response. FDA’s 2026 cybersecurity guidance recommends that cybersecurity controls be treated as design inputs with acceptance criteria.
10. Treating launch as the end of development
Production and postmarket information can reveal process variation, supplier changes, use error, software anomalies, security vulnerabilities and failure modes that were not visible in development. The organization needs a controlled path from those signals back to investigation, risk review and corrective action.
Before launch, define complaint intake, service records, product identification, escalation, regulatory-reporting assessment, trend review, cybersecurity monitoring and change control. Current 21 CFR Part 820 includes specific record expectations for complaints and servicing activities.
Use a readiness review before committing major investment
| Decision | Minimum questions |
|---|---|
| Enter detailed design | Are intended use, major risks, regulatory premise and core feasibility understood? |
| Freeze architecture | Are critical interfaces, budgets, fault states and manufacturing assumptions resolved? |
| Begin formal verification | Are inputs approved, methods ready and configurations controlled? |
| Begin validation | Are production units or justified equivalents available, and are users and conditions representative? |
| Transfer | Can production reproduce, inspect and test the approved design? |
| Launch | Are regulatory controls, records, feedback channels and postmarket responsibilities operational? |
Keep the quality system proportional and active
FDA’s Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016. The system should be appropriate to the manufacturer’s activities and devices. Proportionality does not mean postponing control. It means applying the right depth of planning, review, evidence and recordkeeping to the product’s risk and complexity.
The strongest prevention is early technical alignment. Product, systems, clinical, regulatory, quality, manufacturing and discipline engineers should resolve the decisions that cross their boundaries while the design can still change.
Outer Reef’s medical-device engineering and program-management work focuses on those system-level decisions from definition through transfer.
