What you will learn
By the end of this topic, you should be able to define the core responsibilities a medical-device startup must own, assemble a proportionate team, connect investment decisions to development evidence and recognise the organisational shortcuts that create expensive regulatory and technical problems later.
The founder's real responsibility
A founder does not need to personally perform every regulatory, quality or engineering activity. The founder does need to ensure that competent people perform the right work, that decision rights are clear and that the organisation retains control of its product and evidence.
Own the purpose
Keep the intended purpose, clinical value, claims, users and use environment coherent as commercial and technical ideas evolve.
Own accountability
Know which legal entity will be the manufacturer and ensure it can meet its obligations. Outsourcing work does not outsource that accountability.
Fund the evidence
Plan for risk management, verification, validation, clinical evidence, transfer and post-market work—not only prototype development.
Protect decisions
Make significant product, supplier, claim and schedule decisions through controlled review with their consequences visible.
A prototype shows that an idea may work. A medical device also needs a controlled definition, justified decisions, managed risks, reproducible manufacture or deployment, objective evidence and lifecycle support.
Define the product before scaling the solution
Early ambiguity about the product drives late redesign. Before committing to architecture, major suppliers or clinical activity, establish a controlled first version of the following:
- The medical purpose, patient benefit and clinical context.
- Intended users, patients, indications, limitations and use environments.
- The claims the company expects to make and the evidence those claims require.
- The device boundary, accessories, software, cloud services, consumables and external dependencies.
- Target markets, likely classification, regulatory route and conformity strategy.
- Product variants and the smallest commercially useful first release.
This definition will evolve, but changes must be deliberate. A new claim, user group, market or connected feature can alter risk, classification, standards, clinical evidence and development scope.
Build capabilities, not an oversized org chart
A small company can combine roles and use external specialists. What matters is that every critical capability has a named owner, sufficient competence, time, authority and access to information.
Executive and product ownership
Accountability for the manufacturer, intended purpose, resources, priorities and release decisions.
Regulatory and quality
Regulatory strategy, QMS, design assurance, submissions, document control, audit readiness and change control.
Technical leadership
System architecture, requirements, interfaces, configuration, integration and technical decision-making.
Clinical, risk and usability
Clinical relevance, evidence planning, risk management, human factors and benefit–risk reasoning.
Verification and validation
Independent evidence strategy, representative configurations, acceptance criteria and anomaly handling.
Supply and lifecycle
Supplier control, design transfer, production or deployment, complaints, surveillance, security and change.
Independence should be proportionate. The person who created a design may perform informal checks, but formal review and verification need enough objectivity to expose assumptions and errors.
Right-size quality from the start
A quality-management system should control important work without burying a small team in paperwork. Start with the processes needed to make decisions repeatable and evidence trustworthy, then expand them as the product and organisation mature.
- Design and development planning, reviews, inputs, outputs, verification, validation, transfer and change.
- Risk management integrated with requirements, architecture, testing and post-market information.
- Document, record, configuration and software version control.
- Competence, training and clear approval authorities.
- Supplier selection, agreements, monitoring and change notification.
- Nonconformity, corrective action, complaints and post-market feedback.
Quality is not a department that documents engineering after the event. It is the operating system through which the company plans, reviews, approves, learns and demonstrates control.
Organise work around the lifecycle and evidence
Purpose and plan
Agree the product definition, markets, responsibilities, development route, major uncertainties and evidence strategy.
Founder question: Do we know what we are making, for whom, why and under whose accountability?Needs, requirements and risk
Turn the clinical and user context into measurable requirements while identifying hazards and defining risk controls.
Founder question: Are our promises becoming testable design inputs?Architecture and implementation
Allocate functions and controls, manage interfaces and create design outputs under configuration control.
Founder question: Can the team explain why this architecture is suitable and what baseline is being built?Verification and validation
Show that outputs meet inputs and that the resulting device meets user needs and intended use in representative conditions.
Founder question: Does the evidence answer the right questions with the right product configuration?Transfer and release
Establish controlled manufacture or deployment, qualified suppliers, release criteria and regulatory readiness.
Founder question: Can the approved organisation repeatedly provide the verified product?Post-market and change
Monitor performance, investigate problems, maintain security and compliance, and feed learning back into product and risk decisions.
Founder question: Who owns the device after launch, and how will we detect and respond to change?Connect decision gates to funding
A gate is not a presentation ceremony. It is a decision about whether the available evidence justifies more money, greater commitment or increased exposure. Each gate should state what must be known, what uncertainty remains, who approves the decision and what happens next.
Investor and board milestones should describe evidence, not just activity: “critical user needs validated and regulatory route confirmed” is stronger than “prototype completed.”
Use suppliers and consultants without losing control
External experts can give a startup speed and experience, but fragmented outsourcing can leave the manufacturer unable to explain, maintain or defend its own device.
- Define the work, deliverables, acceptance criteria, records, approvals and interfaces.
- Secure access to design files, source material, raw evidence, configuration history and necessary intellectual property.
- Set expectations for competence, quality controls, confidentiality, security and change notification.
- Review supplier outputs as part of the startup's controlled development process.
- Retain enough internal knowledge to make product, risk, release and lifecycle decisions.
Common startup failure patterns
“The working prototype is nearly the product.”
It may not represent controlled requirements, production components, representative software, verified risk controls or a reproducible process.
“We will add regulatory and quality before submission.”
Late control cannot reliably reconstruct missing decisions, configurations, risk reasoning and evidence.
“The contractor owns that subsystem.”
The manufacturer still needs to define, review, integrate, verify and maintain the outsourced work.
“Verification can be planned after design.”
Acceptance criteria, testability, samples, configurations and evidence needs influence requirements and architecture.
“Launch is the end of development.”
Complaints, surveillance, vulnerabilities, supplier changes, obsolescence and corrective action require sustained ownership and resources.
A practical first 90 days
Days 1–30: establish direction
Control the intended purpose and claims, identify the legal manufacturer and markets, outline the regulatory route, name capability owners and assess the largest gaps.
Days 31–60: establish control
Approve a development plan, implement the minimum QMS, begin risk management and requirements, define architecture ownership and create the evidence strategy.
Days 61–90: establish governance
Run formal reviews, align supplier contracts, baseline traceability, agree decision gates and introduce a concise product-readiness dashboard.
The founder's product-readiness dashboard
- Is the intended purpose and claim set current, approved and understood?
- Are the regulatory route, classification assumptions and key standards justified?
- Does every critical capability and product interface have a named owner?
- Are the highest risks, assumptions and unresolved decisions visible?
- Are requirements, architecture, risk controls and evidence connected?
- Is formal testing using the correct, representative configuration?
- Are suppliers, manufacture or deployment and release controls becoming ready?
- Does runway cover the evidence and lifecycle work needed for the next meaningful gate?
Authoritative starting points
- ISO 13485:2016 — Medical-device quality-management systems
- ISO 14971:2019 — Application of risk management to medical devices
- US FDA Quality Management System Regulation
- US FDA QMSR: Design and Development
- European Commission — Medical-device regulations and guidance
- Regulation (EU) 2017/745 on medical devices
Applicable obligations depend on the product, claims, classification, manufacturer, markets and lifecycle arrangements. Use current legislation, recognised standards and competent regulatory advice for the specific device.