Medical device prototyping is the iterative process of building early versions of a device or its software to test an idea, workflow, or design approach before committing to full development. For connected and software-driven devices, prototyping usually moves through three stages: a proof of concept that shows the core idea can work, a prototype that shows how users will interact with it, and a minimum viable product (MVP) that is real, working software with the smallest feature set needed to validate the product.
Prototyping is where teams learn the most for the least money. It is also where many teams create problems they pay for later, because FDA design controls start at a specific point in development, and a prototype isn’t a finished design. This guide covers the stages of medical device prototyping, how a software prototype becomes an MVP, and where FDA’s expectations begin.
Proof of concept, prototype, and MVP
People often use these terms interchangeably, but they answer different questions.
Stage | Question it answers | What it usually looks like | Who uses it |
|---|---|---|---|
Proof of concept | Can this work at all? | A bench test, a sensor reading on a laptop, a quick script | The engineering team |
Prototype | How will people use it, and is the design approach right? | A clickable interface built in a design tool, or a rough functional build | Designers, engineers, clinicians, and target users in feedback sessions |
MVP | Does the product deliver value with the smallest set of features? | Working software with essential features, built to be extended | Pilot users, clinical study participants, or early customers |
Prototypes vary in fidelity. A visual prototype, such as an interactive design built in Figma, tests screens and workflows without working code. A functional prototype runs real code, often to test a sensor connection or a data flow. Both are prototypes: they exist to learn, not to ship.
FDA describes the same idea in its Design Control Guidance: “It may be reasonable to develop a rapid prototype to explore the feasibility of an idea or design approach.” It also warns that “manufacturers should avoid falling into the trap of equating the prototype design with a finished product design.”
Software prototyping vs hardware prototyping
Most medical device prototyping guides focus on hardware: 3D printing, machining, and molding enclosures. Connected devices also need a software prototype, and it often matters more because users and clinicians actually interact with the app, cloud, and dashboards.
Hardware prototyping | Software prototyping | |
|---|---|---|
Main tools | 3D printing, CNC machining, rapid tooling | Design tools such as Figma, device simulators, prebuilt software platforms |
Iteration speed | Days to weeks per physical version | Hours to days per design change |
What it tests | Form, fit, materials, ergonomics | Workflows, screens, data flow, connectivity, alerts |
Common trap | Designing for prototype methods that do not scale to production | Shipping prototype code as the product |
The two tracks do not have to wait for each other. Software teams can build and test against a device simulator before final hardware exists, so the app is ready when the hardware is.
When FDA design controls begin
This is the most important line in medical device prototyping. Early concept and feasibility work is not under design controls. Formal design and development is.
FDA’s inspection guide on design controls says “the firm’s development of concepts and the conduct of feasibility studies are not subject to the design control requirements.” It also says “once the firm decides that a design will be developed, a design plan must be established,” and that design controls “must be applied no later than the time the firm approves its first set of inputs.”
Under the FDA’s Quality Management System Regulation (QMSR), effective February 2, 2026, design and development requirements come from ISO 13485 clause 7.3, which 21 CFR 820.10(c) applies to Class II and III devices and to Class I devices automated with computer software. The 1997 guidance and the inspection guide predate the QMSR, but their line between feasibility work and design and development still describes the transition well.
What that means in practice:
- Prototypes can be fast and informal. Proof-of-concept code and early design explorations do not need full design control records.
- The decision to develop starts the clock. Once you decide to build the product and approve design inputs, you need a design plan and controlled records.
- A concept is not a requirement. FDA’s guidance notes that “a concept document may be the starting point for development, but it is not the design input requirement.”
- Documentation should not be rebuilt later. FDA’s premarket software guidance says design history documentation should be “synchronized with their software development,” and that documentation created long after the work “could raise concerns.” See our guide to the design history file for medical device software.
From prototype to MVP software: five steps
This is the process Sequenex uses with device companies to move from requirements to MVP software.
Step 1: Write a software requirements document
A software requirements document (SRD) describes what the software must do, in language the whole team can follow. For a medical device, it typically covers:
- Purpose, scope, and intended users
- Functional requirements: what the software does
- Non-functional requirements: performance, security, privacy, and reliability
- Data requirements: what is collected, stored, and shared
- Interface requirements: devices, apps, cloud services, and health record systems
- Regulatory considerations, such as FDA requirements, HIPAA, and GDPR
- Testing and documentation expectations
The SRD is not yet a set of controlled design inputs, but it is the raw material for them. A clear SRD makes the move into design controls much smoother.
Step 2: Review the SRD with your software partner
All stakeholders review the SRD together, including product, clinical, regulatory, and engineering leads from the device company and the development partner. The goal is to resolve ambiguities, surface assumptions and risks, check technical feasibility, and agree on acceptance criteria before design work starts.
Step 3: Build the prototype
The team turns the SRD into an interactive prototype, typically in a design tool such as Figma, so users and clinicians can click through real workflows. Each feedback round refines the screens and flows. This is also the right time for early usability work: FDA’s human factors guidance, reissued in August 2026, describes formative evaluations as a way “to inform device user interface design while it is in development.” See our guide to IEC 62366 usability engineering.
Step 4: Define the MVP features and design
The prototype becomes the blueprint. The team prioritizes features by user need, risk, and regulatory impact, then turns the chosen features into design specifications. As the product moves into design and development, requirements become controlled design inputs, risks are analyzed under ISO 14971, and the software architecture is set.
Step 5: Build the MVP
Developers build the MVP in short iterations, test as they go, and keep documentation in step with the code under an IEC 62304 software lifecycle. FDA’s software guidance accepts this approach: it “acknowledges that modern development practices may employ incremental or evolutionary software development practices.” The MVP then supports pilots, clinical studies, or launch, depending on the product’s regulatory pathway.
What to keep from a prototype, and what to throw away
The prototype’s value is what you learned. Its code is usually the least valuable part.
Keep | Rewrite or replace |
|---|---|
Validated workflows and screen designs | Prototype code written without requirements or tests |
User and clinician feedback, documented | Hard-coded data, shortcuts, and disabled security |
Requirements discovered during testing | Unreviewed third-party libraries |
Risks and use errors you observed | Architecture that cannot support updates, security, or scale |
Interface and data flow decisions | Anything with no record of how it was built or tested |
If you plan to reuse prototype code in the product, bring it under your software lifecycle deliberately: document it, review it, test it, and assess its risks, rather than letting it slip into the product unexamined.
How a software platform shortens the path
Much of the early work in connected device software is the same across products: mobile apps, user accounts, device pairing, a secure cloud, dashboards, and an admin portal. Building all of it from scratch for every MVP is slow.
Sequenex’s NEX platform provides prebuilt, customizable iOS and Android apps, a secure data cloud, dashboards, and an admin portal for connected medical devices, developed under an ISO 13485-certified quality management system in accordance with IEC 62304 and ISO 14971. Teams build on that foundation and focus on what makes their device different. NEX is not FDA-cleared or a regulatory submission itself; it supports the manufacturer’s design and development documentation.
AI also speeds up the build, inside the same design-first process. See how we use AI in medical device software engineering.
Common prototyping mistakes
- Treating the prototype as the product. FDA’s guidance notes that prototypes “lack safety features and ancillary functions necessary for a finished product.”
- Starting design and development without a design plan. Once you decide to develop, design controls apply.
- Reconstructing documentation before submission. Build records as you go, not in the last month.
- Skipping early user testing. Formative evaluations are cheapest when designs are still changing.
- Locking in architecture too early, or too late. Decide on connectivity, data, and security architecture before the MVP, when change is still cheap. See component architecture for SaMD development.
- Waiting too long to talk to FDA. A Pre-Submission under FDA’s Q-Submission program is voluntary, and FDA says feedback “is most effective when requested prior to execution of planned testing.”
Frequently asked questions
What is medical device prototyping?
Medical device prototyping is the iterative process of building early versions of a device or its software to test an idea, a workflow, or a design approach before full development. For software, prototypes range from clickable interface designs to rough functional builds that test connectivity or data flow.
What is the difference between a prototype and an MVP?
A prototype exists to learn: it tests whether a design approach and workflows work, and it is not meant to ship. An MVP, or minimum viable product, is working software with the smallest feature set needed to validate the product with real users. A prototype usually comes first and shapes the MVP’s design.
Do FDA design controls apply to prototypes?
Not to early concept and feasibility work. FDA’s inspection guide says concept development and feasibility studies are not subject to design control requirements. Once a company decides to develop a design and approves its first design inputs, design controls apply, now through ISO 13485 clause 7.3 under the QMSR.
Can prototype code be used in the final product?
Yes, but only if you bring it under your software lifecycle: document it, review it, test it, and assess the risk like any other code. Much prototype code is written for speed without requirements or tests, so rewriting it is often faster and safer than retrofitting the records.
What tools are used for medical device software prototyping?
Design tools such as Figma are widely used for clickable interface prototypes. Functional prototypes use device simulators, development kits, and prebuilt software platforms that provide apps, cloud, and dashboards, so teams can test real data flows before final hardware is ready.
Prototype faster, without rework, with Sequenex
The fastest path to an MVP is a prototype that teaches you what to build, followed by development that produces its own records as it goes.
Sequenex helps device companies move from concept to MVP software, from requirements and prototypes to connected apps, cloud, and dashboards built on NEX. See our medical device software development services or contact us to talk through your project.
