Questions to Ask Before Signing a Medical Device Development Contract

TL;DR

How to make sure your next statement of work creates evidence, preserves capital, and gives the business a clearer path forward.

A development contract is usually read as a purchase: a scope of work, a price, a schedule, and a list of deliverables at the end. It is more useful to read it as a specification for the evidence your company will own six or twelve months from now. The contract decides which risks get retired, which questions stay open, and what a board, an investor, or a regulator will actually be looking at once the budget is spent.

That framing changes how proposals compare. Price, schedule, and deliverables matter, and they are the easiest things to line up side by side, which is why they tend to dominate the conversation. They are also the least likely to explain why one program ends with a company that can raise its next round and another ends with a working prototype that nobody can build on.

Two proposals can quote similar numbers for what looks like the same phase and leave behind completely different assets. One ends with a benchtop demonstration and a set of exploratory reports. The other ends with a controlled design, a populated risk file, verification data, and units a team can put in front of a clinician. Both are legitimate answers to different milestones, and the expensive version of this is not finding out which one you bought until the phase has closed and the next decision is already due.

The questions below are meant to show what you will actually own at the end of the phase, which risks the scope will retire, and which costs and decisions the scope pushes downstream. Most are not legal questions. They are program questions that need to be made explicit in a legal document.

1. What Milestone Is This Contract Meant to Unlock?

Start with the decision on the other side of the work. Depending on the stage of the company, the objective might be to demonstrate technical feasibility, integrate the major subsystems into a representative prototype, retire a critical technical or regulatory risk, prepare for a regulatory interaction, produce devices for a clinical or usability study, complete design verification, or transfer a product into pilot manufacturing. Each of those implies a different level of documentation, a different definition of done, and a different cost.

For early-stage companies, development milestones and financing milestones are usually the same milestone described in two vocabularies. An integrated prototype may be what supports a funding round. A successful feasibility study may be what strengthens a grant application or a strategic partnership. Released clinical units may be what lets you generate the evidence your next investment decision depends on. If you scope the contract against the engineering objective alone, your partner can deliver it in full and you still end up without the thing the business needed.

Getting to that answer takes only a few questions, and they are worth answering in writing rather than in a meeting:

• What will we be able to credibly claim when this phase is complete?
• What data and deliverables will support that claim?
• Will the milestone be meaningful to investors, regulators, clinicians, or strategic partners?
• Does the scope produce enough evidence to materially reduce risk?

Investors do not fund completed task lists. They fund evidence that the next stage is achievable, which is why the answer to the first question matters more than the length of the deliverables list underneath it. A weak answer usually means the phase is defined by activity rather than evidence: the team may complete the work and still lack a credible proof point for the next financing, regulatory, clinical, or partnership decision.

2. What Exactly Does “Done” Mean?

Terms such as prototype, Alpha, Beta, design complete, clinical-ready, and production-ready are useful shorthand between people who already share context. They are not acceptance criteria. A prototype might mean a benchtop assembly that demonstrates a single technical principle, or an integrated system with representative hardware, software, industrial design, and performance. Both are honestly described by the same word, and the gap between them can be most of a development budget.

The same ambiguity shows up in clinical-study readiness, where the distance is larger than it looks. A prototype that could eventually be developed for clinical use is a different object from a documented and released device suitable for the intended study. Depending on the study, the device risk, and the jurisdiction, clinical investigations can carry requirements for regulatory and ethics approvals, investigational labeling, sponsor and investigator responsibilities, monitoring, records, and reporting. The contract should say plainly which of those activities are inside the scope and who is accountable for each one. Where the contract is silent, the missing work usually reappears later as a change request, a dependency on you, or an unplanned cost.

A statement of work removes the ambiguity by pinning down every deliverable:

• The intended use and maturity of each deliverable.
• The conditions under which performance will be evaluated.
• The objective acceptance criteria.
• Who has authority to approve the deliverable.
• Whether documents are exploratory work products or controlled development records.
• What questions will remain unresolved when the phase ends.

That last item is the one most often left out, and it is the one that tells you what you are still carrying.

Without objective acceptance criteria, a disagreement over “done” can quickly become a scope, invoice, and schedule dispute. A deliverable without them is a description rather than a milestone, and there is no defensible moment at which either party can say the phase is over.

3. Which Assumptions and Exclusions Could Change the Cost or Schedule?

Every development estimate rests on assumptions, and that is not a problem by itself. The problem is assumptions that stay implicit until one of them turns into a cost, schedule, or scope surprise. An estimate with its assumptions written down is easier to challenge before the work starts and easier to renegotiate honestly once something moves.

An estimate is only as good as the assumptions underneath it, so ask for those assumptions explicitly:

• What technical, regulatory, clinical, manufacturing, and commercial assumptions were used to create the estimate?
• What information, decisions, equipment, samples, or subject-matter expertise must you provide, and when must it be available?
• Are component costs, prototype materials, laboratory testing, tooling, travel, and subcontractor fees included?
• What happens if a critical assumption proves incorrect?
• When must the development partner notify you of a likely cost or schedule overrun?

Your own dependencies deserve particular attention, because they are the assumptions you control and therefore the ones most likely to slip. A phase built around a sample set, a clinical contact, or a decision you owe by a certain week can stall on that single item while the rest of the plan stays technically on track.

Exclusions are worth reading with the same suspicion. Consider a contract that refers to development of clinical units. That phrase can cover only the design of the device, or it can extend to procurement, assembly, inspection, testing, documentation, packaging, labeling, release, shipping, replacements, and support through the study. Those are different bodies of work with different costs and different owners, and the difference between the narrow reading and the broad one is not a rounding error. For even a modest clinical build, procurement, assembly, inspection, release, packaging, and study support can approach or exceed the effort of the design work itself. That is why the broad reading of “clinical units” can be materially larger than the design-only reading, even when the unit count is small.

None of this is an argument for a plan that never changes. Good change control does not prevent change. It makes new information visible early enough that the team can make a deliberate decision, rather than discovering the decision was already made for them.

4. Does the Scope Fit the Path the Product Has to Travel?

A project can be technically in scope and still be off-path. A low-cost first phase looks attractive on a comparison sheet, and it creates limited value if the resulting design cannot carry the intended regulatory, clinical, manufacturing, or commercial route. Redoing work later costs more than scoping it correctly the first time, and the bill usually arrives at the worst moment, when a study date or a financing window is already fixed.

So the scope should account, as applicable, for product requirements and intended use, risk management and design controls, human factors and usability, software and cybersecurity, verification and validation, clinical evidence, supply chain and component strategy, manufacturing transfer and process development, and product cost at commercial volumes. Quality-system expectations belong in that list rather than in a later phase. In the United States, the FDA’s current Quality Management System Regulation incorporates ISO 13485:2016 by reference for finished device manufacturers, which is one reason design and development expectations are cheaper to define at the start than to retrofit into a design history file that was never built to hold them.

None of that means completing every downstream activity in the first phase. It means separating the requirements that must shape the design now from the ones that can wait:

• Which downstream requirements must influence the design now?
• Which activities can be safely deferred?
• Which long-lead items should begin early?
• What is the likely total cost and timeline to reach the next meaningful endpoint?
• Does the current phase reduce future work, or simply postpone it?

The requirements that are most expensive to discover late are usually the ones that constrain architecture or materials: sterilization and biocompatibility, electrical safety and EMC, cybersecurity, human factors, critical component availability, and the manufacturing validation itself. They do not all need to be completed early, but the design should not quietly make them impossible or force a major redesign later.

With stage-appropriate development, the goal is enough discipline to reach the current milestone without investing early in scale, optimization, or complexity your company does not need yet, which is what lean means here without it becoming a dead end.

5. Who Owns the Decisions, Evidence, and Product?

A good development partner will give advice, challenge assumptions, and recommend a direction. That does not settle who decides, and a contract that leaves decision rights implicit tends to resolve them under time pressure, which is the worst condition for it.

Decision rights are cheaper to settle line by line before signing than under schedule pressure later:

• Who owns the product requirements and intended use?
• Who approves clinical claims and regulatory strategy?
• Who decides when technical performance is sufficient?
• Who accepts business and program risk?
• Who has authority to change scope, schedule, or budget?
• What response times are expected from you?
• Who maintains the risk file, traceability, design documentation, and project records?

Ownership of the deliverables needs the same treatment, and the question is narrower than it sounds. Owning the physical prototype is not the same as owning the knowledge and the files needed to keep developing it. A company can hold hardware it cannot modify, reproduce, or transfer to another team.

So ask specifically whether you receive native CAD and design files, source code and build instructions, schematics and printed circuit board files, bills of materials and supplier information, test methods with raw data and analysis, manufacturing procedures and fixture designs, and the controlled quality and regulatory documentation. The agreement should also separate background IP brought into the program, newly created IP, third-party technology, and open-source software, since each carries different terms and different constraints on what the company can do commercially. The gaps that become most painful are often native design files or source code, and the manufacturing or test knowledge needed to reproduce the device. A PDF drawing package may document what was built without giving the next team what it needs to change, build, or verify it.

Clear ownership protects both parties. It is also what preserves your ability to move into manufacturing, bring in another specialist, or change direction without starting over.

6. How Will Risk, Bad News, and Funding Changes Be Handled?

Medical device programs rarely follow the original plan exactly. Technical results challenge the preferred architecture, regulatory feedback changes the evidence strategy, components go unavailable, and fundraising takes longer than the schedule assumed. The test of a contract is not whether the plan holds but how quickly a change becomes visible and how deliberately the team gets to respond.

What exposes how a partner handles a change is mostly reporting and pace:

• What are the highest risks at the beginning of the engagement, and which of them is this phase expected to retire?
• What evidence is required to pass each phase gate?
• How frequently will cost, schedule, risk, and forecast information be reported?
• When must the project pause for your decision?
• What happens if the program is paused or funding is delayed?
• How will incomplete work, materials, prototypes, data, and files be transferred?
• Can each phase leave behind a useful and coherent asset?

The last two carry more weight than their position on the list suggests. Funding delays are common enough that a contract should already know what happens during one, and a phase that only has value if the next phase starts on time converts a financing delay into a technical loss.

One question tends to be more revealing than any of the above: under what circumstances would you advise us not to continue the program, or not to proceed to the next phase?

There are legitimate reasons a development partner may recommend stopping, pausing, or changing direction. Early feasibility work may show that the core technology is not mature enough to support the intended product, or that achieving the required performance would demand years of additional research and a development investment far beyond what the business case can support. In other cases, the technology may work technically but fail to create enough clinical value to justify its cost or complexity. The proposed device may not fit naturally into the workflow of patients, clinicians, or other users, or the regulatory pathway and evidence requirements may make the original product strategy impractical.

In each of these cases, the right answer may not be to abandon the underlying opportunity, but to pivot and reconsider the technology, intended use, product requirements, or development path before committing more capital.

A partner who can explain where those decision points lie has thought about your capital as something to protect rather than something to spend down against the current scope. A vague answer is useful information in itself: it may suggest the partner has organized the engagement around completing contracted work rather than making an explicit go, pause, pivot, or stop decision when the evidence changes.

A good contract does not remove the uncertainty in a development program but gives both parties a disciplined way to learn from it.

Related Resources

Questions to Ask Before Signing a Medical Device Development Contract

Most medical device development contracts get compared on price and schedule. Here are the questions that decide what the money actually buys.

What Non-Technical Buyers Should Know Before Choosing an EE Partner

Choosing an EE partner is a program risk decision, not a staffing decision. Early architecture choices carry through to certification, and the wrong partner can cost far more than their hourly rate suggests.

When the CM Says No: What to Do When Your Contract Manufacturer Rejects Your Early-Stage Build

You’ve cleared the toughest engineering hurdles and proven your design works. Then, just as you prepare to scale, your contract manufacturer turns you down.

Free Medical Device RFP Template

Choosing the right design and development partner is one of the most critical decisions in bringing a medical device to market.