1. Define what the prototype must prove

“Build a prototype” is not a sufficiently specific development objective. A prototype may be intended to prove one technical principle, demonstrate a complete workflow, generate investor evidence, support a clinician review, or provide data for a regulatory submission. Each purpose requires a different level of fidelity.

Start by writing a short prototype charter that answers five questions:

• What decision will this prototype support? For example, will the team decide whether to continue development, select a sensor, or begin a formal design phase?
• Who will interact with it? The user may be a patient, surgeon, nurse, technician, caregiver, or a combination of stakeholders.
• What functions must operate? Separate essential functions from features that can wait.
• What evidence must be collected? Evidence might include accuracy, force, flow rate, battery life, thermal performance, software response time, or usability observations.
• What does the prototype not prove? A 3D-printed enclosure may demonstrate ergonomics but not sterilization compatibility, long-term durability, or production material performance.

This distinction prevents a proof-of-concept demonstration from being mistaken for a working prototype. A proof of concept may show that a mechanism, algorithm, or sensing method is feasible. A working prototype should demonstrate that the relevant system functions together in a representative environment, with defined limitations and documented test results.

2. Turn the idea into a specific clinical use case

Many medical device concepts begin with a compelling observation: a procedure is inefficient, a diagnostic decision is delayed, a patient struggles with adherence, or a clinician lacks useful information. The next step is to convert that observation into a precise use case.

Document the intended use

Describe the condition, procedure, or workflow the device is intended to address. Then identify the intended user, patient population, use environment, duration of use, and expected clinical decision. A device designed for a hospital operating room may require a very different design from one used by a patient at home.

A useful early statement follows this pattern:

“The device is intended to help [specific user] perform or support [specific task] for [defined patient or use population] in [defined environment] by providing [measurable function or output].”

This is not a substitute for a final regulatory intended-use statement. It is a working definition that helps align engineering, clinical, quality, and commercial decisions.

Map the workflow instead of designing in isolation

Observe or reconstruct the complete workflow before selecting components. Record what happens immediately before and after the device is used, what information the user needs, how the device is cleaned or stored, what happens when something goes wrong, and which steps are vulnerable to distraction or misunderstanding.

For example, a handheld device may function correctly in a laboratory but fail in practice because the clinician must change gloves, maintain sterility, look away from the patient, or operate the device while handling another instrument. Workflow constraints should become design inputs rather than late-stage surprises.

3. Establish an initial regulatory and quality strategy

Founders do not need to complete a full regulatory submission before building an early prototype, but they should understand the likely regulatory direction. FDA device classification is risk-based. Class I devices generally rely on general controls, Class II devices may require general and special controls, and Class III devices typically require the most rigorous premarket review. The appropriate pathway may include a 510(k), De Novo request, or Premarket Approval application, depending on risk and whether a legally marketed predicate exists. ([fda.gov](https://www.fda.gov/patients/device-development-process/step-1-device-discovery-and-concept?utm_source=openai))

Classification and pathway are not determined solely by how complicated a device looks. Intended use, indications, claims, technology, invasiveness, duration of contact, energy sources, software functions, and potential hazards all matter. A preliminary regulatory assessment should therefore examine:

• Whether comparable or predicate devices exist.
• What claims the founder intends to make.
• Whether the device is active, powered, software-enabled, implantable, sterile, or patient-contacting.
• Whether the device measures, diagnoses, monitors, treats, or supports a clinical decision.
• What foreseeable misuse or failure could do to a patient or user.

Quality planning should begin early as well. ISO 13485 provides an internationally recognized framework for quality management in the design and manufacture of medical devices, while ISO 14971 focuses on identifying, evaluating, controlling, and monitoring device-related risks across the product lifecycle. ([committee.iso.org](https://committee.iso.org/standard/59752.html?utm_source=openai))

As of February 2, 2026, the FDA’s Quality Management System Regulation, or QMSR, became effective and amended the prior quality system requirements to align more closely with ISO 13485:2016. Founders developing for the U.S. market should confirm the current expectations with qualified regulatory and quality professionals rather than relying on outdated checklists. ([fda.gov](https://www.fda.gov/medical-devices/medical-devices-news-and-events/town-hall-quality-management-system-regulation-risk-and-design-and-development-01142026?utm_source=openai))

4. Build requirements and risk controls at the same time

A vague concept becomes engineerable when it is expressed as measurable requirements. Requirements should describe what the device must do, not simply how the team currently imagines building it.

Examples of useful early requirements

• The device shall measure pressure within a defined accuracy range over a specified operating range.
• The device shall operate for a stated minimum duration on one battery charge.
• The device shall be usable with one gloved hand.
• The patient-contacting material shall be identified and assessed for its intended contact type and duration.
• The device shall provide an unambiguous indication when a measurement is invalid.
• The enclosure shall withstand a defined drop, cleaning exposure, or environmental condition.

Each requirement should have a planned method of verification, such as inspection, analysis, bench testing, software testing, or simulated-use evaluation. If a requirement cannot be measured or evaluated, it may be too ambiguous to guide design.

Use risk analysis to shape the design

Risk management should not be treated as paperwork completed after the prototype works. FDA design-control guidance explains that risk management begins with design input requirements and should be integrated into the design process so unacceptable risks can be addressed when changes are easier and less expensive. ([fda.gov](https://www.fda.gov/media/116573/download?utm_source=openai))

At the prototype stage, create an initial hazard analysis or preliminary risk assessment. Consider hazards such as incorrect readings, missed alarms, unintended movement, excessive temperature, electrical shock, loss of power, software errors, contamination, sharp edges, incorrect assembly, and foreseeable misuse.

For each significant risk, ask:

1. What hazardous situation could occur?
2. What harm could result?
3. How might the hazard arise during normal use or foreseeable misuse?
4. Can the risk be eliminated through the design?
5. If not, can protective measures or alarms reduce it?
6. What information, labeling, or training is needed?
7. How will the effectiveness of the control be verified?

Risk controls should preferably be implemented through inherently safer design choices before relying on warnings or user training. The risk file should evolve as the architecture, components, software, and use environment become better understood.

5. Select the architecture before optimizing the details

Once the use case, requirements, and major hazards are defined, the team can select a system architecture. This is where mechanical, electrical, software, systems, manufacturing, and quality decisions begin to interact.

Develop a functional block diagram showing inputs, outputs, energy sources, sensors, actuators, user interfaces, data pathways, mechanical interfaces, and failure responses. For a connected device, include communication links, data storage, cybersecurity considerations, cloud dependencies, and what happens when connectivity is unavailable. For a disposable product, identify material, joining, packaging, and sterilization assumptions. For a reusable product, include cleaning, disinfection, maintenance, and service requirements.

Architecture work also helps identify “make-or-buy” decisions. An off-the-shelf component may accelerate an early demonstration but introduce supply, obsolescence, software, environmental, or regulatory limitations. A custom component may offer better performance but require more development time and tooling. The right answer depends on the prototype objective and the intended product pathway.

6. Plan prototypes as a sequence of learning cycles

Medical device prototyping is usually more efficient when the team builds several targeted iterations rather than attempting to create a polished final-looking product immediately.

Prototype 1: technical feasibility

The first build should answer the highest-risk technical question. It may use a development board, off-the-shelf sensor, temporary fixtures, 3D-printed parts, or manual data collection. The objective is to determine whether the core physical or digital principle works under controlled conditions.

Prototype 2: integrated function

The next iteration combines the major subsystems. It should reveal interface problems, power limitations, signal noise, thermal behavior, mechanical interference, software timing issues, and basic failure modes. At this stage, the team should begin recording configuration, component sources, test conditions, and observed deviations.

Prototype 3: representative form, fit, and function

A higher-fidelity prototype should approximate the intended user interaction and operating environment. It may still use nonproduction materials or fabrication methods, but the team should identify where those substitutions limit the conclusions that can be drawn.

Use an iteration plan with explicit exit criteria. For example, the team may not advance to usability evaluation until the prototype demonstrates a defined accuracy range, completes a specified number of operating cycles, and has no unresolved high-severity failure mode that would invalidate the session.

FDA characterizes prototype development as controlled laboratory work intended to refine the device and reduce the risk of harm before use in people. A prototype should not be represented as clinically ready merely because it operates during a demonstration. ([fda.gov](https://www.fda.gov/patients/device-development-process/step-2-preclinical-research-prototype?utm_source=openai))

7. Test what the prototype proves—and document what it does not

Testing should be planned around the requirements and risks, not performed only when the team has spare time. A practical early verification matrix can include the requirement, test method, equipment, acceptance criteria, sample size or number of cycles, responsible person, result, and follow-up action.

Verification versus validation

Verification asks whether the design output meets the specified design input. For example, does the device deliver the required flow rate or battery life?

Validation asks whether the device meets user needs and intended use in the applicable or simulated environment. For example, can the intended clinician perform the task safely and consistently using the device in a realistic workflow?

Both are necessary. A device can meet a technical specification and still be confusing, difficult to clean, awkward to position, or unsuitable for the actual clinical environment.

Include human factors early

Human factors evaluation should begin before the design is visually polished. Observe representative users performing realistic tasks, including setup, normal operation, alarm response, cleaning, charging, troubleshooting, and shutdown. Pay attention to workarounds, hesitation, incorrect assumptions, skipped steps, and conditions that increase the chance of use error.

Early formative studies are intended to improve the design. They are different from a final validation study and should be planned with appropriate regulatory and human-factors expertise.

Control software and data assumptions

If software contributes to diagnosis, monitoring, treatment, control, or user decision-making, it belongs in the overall system risk analysis. Define software requirements, interface behavior, error handling, version control, test cases, and change-management expectations early. Also document which features are simulated, manually operated, or not yet implemented in the prototype.

8. Design for manufacturing before the design is frozen

A prototype that works once is not necessarily a product that can be manufactured consistently. Design for manufacturing and assembly should begin while the team still has flexibility to change materials, tolerances, fasteners, seals, interfaces, and component selections.

For each major part or assembly, consider:

• How many steps are required to manufacture and assemble it?
• Can the critical dimensions be measured reliably?
• Are tolerances realistic for the selected process?
• Will the materials, adhesives, coatings, or lubricants be available at production volumes?
• Can the device be inspected, cleaned, packaged, sterilized, serviced, and shipped as intended?
• What happens if a supplier changes a component or a part is assembled incorrectly?
• Which characteristics require process validation rather than simple inspection?

Use 3D printing when it is the fastest way to learn about fit, ergonomics, mechanism travel, or enclosure geometry. However, do not assume that a printed material represents the strength, chemical resistance, surface finish, dimensional stability, biocompatibility, or sterilization behavior of the eventual production material.

Manufacturing input is especially important before investing in hard tooling or conducting expensive testing. A late design change can invalidate test fixtures, samples, packaging studies, supplier work, and documentation.

9. Decide when an engineering partner is the right investment

An early-stage founder does not need to build an entire engineering department before testing an idea. However, medical device development often spans mechanical engineering, electrical engineering, systems engineering, software, industrial design, manufacturing, quality, regulatory strategy, human factors, and project management.

An experienced product development partner can help the founder make tradeoffs early, define a realistic development plan, identify technical and regulatory risks, and create the documentation needed to preserve design intent. The partner should contribute more than isolated CAD work or a one-time prototype build.

A65 Consulting supports medical device founders with specialized teams and product development expertise, helping clients move from research and conceptualization through engineering, manufacturing transfer, and cost optimization. Its capabilities can be explored through the A65 Consulting services overview.

Questions to ask prospective firms

• Have you developed devices with similar risk, user, anatomy, technology, or manufacturing requirements?
• Can you support requirements, risk management, verification, usability, and manufacturing—not only mechanical design?
• How do you manage design ownership, documentation, communication, and change control?
• Can you provide senior technical leadership as well as hands-on engineering?
• What assumptions would you challenge in the first month?
• Can you explain what the proposed prototype will and will not demonstrate?
• Can you support transfer to a contract manufacturer or internal production team?

Before making a decision, review relevant recent projects and ask for a clear description of the firm’s role, deliverables, constraints, and measurable outcomes.

A practical first-90-day plan

Founders can use the following sequence to create momentum without confusing speed with readiness.

1. Weeks 1–2: Define the problem. Document the user, patient, workflow, intended use, unmet need, and assumptions that require evidence.
2. Weeks 2–4: Investigate the landscape. Review competing technologies, comparable devices, likely FDA classification, applicable standards, reimbursement assumptions, and manufacturing constraints.
3. Weeks 3–6: Establish requirements and risks. Create initial user needs, design inputs, measurable performance requirements, a preliminary risk analysis, and a prototype test plan.
4. Weeks 5–8: Select the architecture. Compare technical approaches, component strategies, software boundaries, materials, power sources, and manufacturing options.
5. Weeks 7–12: Build and test the first prototype. Focus on the highest-risk technical question, record the configuration, execute defined tests, and update the requirements and risk documentation based on results.

The exact schedule depends on device complexity, availability of clinical input, component lead times, intended use, and regulatory strategy. The value of this plan is not its calendar precision; it is the discipline of converting assumptions into documented learning.

Key takeaways for medical device founders

• Start with the clinical problem: A prototype should address a defined user need and workflow, not merely demonstrate interesting technology.
• Define the evidence goal: Decide what the prototype must prove before selecting its materials, fidelity, and testing approach.
• Bring regulatory thinking forward: FDA classification and pathway assumptions influence claims, requirements, testing, and documentation.
• Integrate risk management: Use risk analysis to shape architecture and design controls from the beginning.
• Separate proof of concept from product prototype: Make clear whether a build demonstrates one principle or an integrated system.
• Test with representative users: Human factors observations can expose workflow problems that bench testing will miss.
• Consider manufacturing early: Materials, tolerances, assembly, inspection, packaging, and supply should influence the design before it is frozen.
• Use expert support strategically: A multidisciplinary engineering partner can reduce rework and provide leadership where an early-stage team lacks internal capacity.
• Document decisions: Requirements, risks, test results, design reviews, and changes create continuity as the project grows.

Frequently asked questions

Move from concept to evidence

The strongest early-stage medical device teams treat prototyping as a structured learning process. They define the clinical problem, identify the most consequential risks, select the right level of prototype fidelity, test against measurable requirements, and use every iteration to improve the product and its development strategy.

If you need help translating a medical idea into a disciplined engineering plan, contact A65 Consulting to schedule a discovery conversation. A multidisciplinary team can help assess your concept, establish priorities, develop the prototype, and prepare for the next stage of product development.