Should a Medical Device Startup Use a Requirements Management Tool Before They Know What Their Product Is?

Here is the honest tension: you are a medical device startup. You have a clinical insight, a rough prototype, and maybe a founding team. You do not have a product specification. You are still figuring out whether the device will be wearable or implantable, Class II or Class III, cleared through 510(k) or De Novo. Telling that team to open a requirements management tool feels like handing a zoning permit application to someone who hasn’t decided what city to build in.

And yet. Every decision you make in these early weeks—what the device will sense, what it will output, what population it will treat, what failure modes are acceptable—will eventually need to appear in a Design History File as a documented design input with traceable rationale. If you don’t capture it now, you will reconstruct it later, under time pressure, during a regulatory submission, from the memories of people who may no longer be on your team.

That reconstruction is not a documentation exercise. It is a credibility problem. FDA reviewers are experienced at distinguishing genuine design history from retroactive rationalization. The discipline question, then, is not whether your startup is ready for requirements management. It is whether you can afford to wait.

What FDA Actually Expects: Design Controls and the Design History File

Design controls are codified in 21 CFR Part 820.30, the quality system regulation that applies to Class II and most Class III medical devices marketed in the United States. The regulation is not long. It describes a set of activities—design and development planning, design inputs, design outputs, design review, design verification, design validation, design transfer, and design changes—and requires that each be documented in a way that allows a reviewer to trace a device from its intended use through its final released form.

The Design History File (DHF) is the repository for all of that documentation. It is not a single document. It is a structured collection of records that demonstrates a device was designed according to an established plan and that the design meets its specified requirements. An FDA inspector who arrives at your facility will ask to see the DHF. What they are reconstructing from it is a decision audit trail: what did you intend, what did you specify, how did you verify that the specification was met, and how did you validate that meeting the specification actually satisfies the user need?

Several things about this framework matter for early-stage teams.

Design controls apply from concept. The regulation does not define a threshold of product maturity before controls kick in. The FDA’s own guidance document on design controls (published by CDRH) states that design controls apply to the design and development of a device, and that design and development begins when the decision to develop a device is made. If you are building hardware and making design decisions, you are in scope.

Design inputs are the hardest part to reconstruct. A design input is a physical, chemical, or other requirement that forms a basis for device design. Design inputs must be complete, unambiguous, and address the needs of the user and patient. They are the bridge between clinical intent and engineering specification. The problem is that design inputs are often established informally, in whiteboard sessions and Slack threads, long before anyone is thinking about regulatory submissions. They are the decisions that feel obvious at the time—obvious enough that no one writes them down with explicit rationale. Six months later, when a contract regulatory affairs consultant asks “why did you choose that sensing modality?” the honest answer is often “we debated it for two hours in March and then just moved forward.” That answer does not belong in a DHF.

Verification evidence is built on top of design outputs, which are built on top of design inputs. The entire verification and validation structure of a submission rests on whether your design inputs were correctly specified. If your inputs were vague, or captured after the fact, or inconsistent with what was actually built, your verification evidence is built on sand. Reviewers will find the inconsistencies. They usually do.

The Retrofitting Problem

Retrofitting requirements means looking at a device that has already been built and working backward to write down what it does, then calling that documentation design inputs and outputs. This is extremely common among device startups. It is also one of the most reliable ways to extend a 510(k) review cycle by months.

The problem is not that FDA prohibits it explicitly. The problem is that retrofitted requirements documentation has recognizable signatures: inputs that perfectly match outputs, rationale that reads like post-hoc justification, absence of rejected alternatives, verification plans that were clearly written after the tests were run. Experienced reviewers identify these patterns. When they do, the questions that follow are detailed, technical, and time-consuming.

Beyond the submission risk, retrofitted requirements create internal problems. Engineers who built a device without formal requirements documentation often have divergent mental models of what the device is actually supposed to do. When you sit down to write requirements after the fact, you discover disagreements you didn’t know existed. Those disagreements have to be resolved somehow—and the resolution changes either the documentation or the device, sometimes both.

There is also a team continuity problem. Medical device development timelines are long. The engineer who made a critical architecture decision in month three may have left the company by month eighteen, when that decision surfaces in a design review question from a notified body or a pre-submission meeting with FDA. If the decision was captured when it was made, with its rationale, it survives that transition. If it wasn’t, it’s gone.

What “Lightweight but Structured” Actually Means

Early-stage teams hear “requirements management tool” and picture the full weight of IBM DOORS: hierarchical requirement databases, formal baselining procedures, change control workflows, import/export negotiations with contractors. That picture is accurate for DOORS, and it is genuinely inappropriate for a five-person startup that hasn’t committed to a product architecture.

But the choice is not between DOORS and a Google Doc. There is a spectrum, and early-stage teams need something at the structured end of lightweight—a tool that enforces enough discipline to make requirements traceable and rationale-linked, but doesn’t require a dedicated configuration manager to operate.

What that looks like in practice:

  • Capture design inputs with explicit rationale. Not just “the device shall measure SpO2” but “the device shall measure SpO2 because the clinical use case requires continuous monitoring of respiratory compromise; oximetry was selected over capnography based on wearable form factor constraints and cost-of-goods targets reviewed on [date] with [stakeholders].”
  • Link requirements to the decisions that generated them. When a clinical advisor tells you that the device needs to work on darkly pigmented skin and you add a performance requirement as a result, that link needs to exist in the tool. You need to be able to answer “where did this requirement come from?” for every design input.
  • Version requirements explicitly when they change. Early-stage products change constantly. That is fine and expected. What matters is that changes are recorded as changes, with a reason, not silently overwritten.
  • Don’t require formality you can’t sustain. A requirements process that requires a three-person sign-off for every change will be abandoned by week four. The process needs to match the team’s actual operating tempo.

How Modern Tools Implement This

The traditional requirements management vendors—IBM DOORS, Jama Connect, Polarion, Dassault Systèmes’ Codebeamer—were built for organizations with established quality systems, dedicated requirements engineers, and products that are already well-defined. They are powerful in that context. DOORS, in particular, has deep integration with formal verification workflows and handles large, complex hierarchical requirement sets in ways that smaller tools don’t. Jama Connect has strong collaborative review workflows and is widely used in medical device companies navigating FDA and EU MDR submissions simultaneously.

But these tools carry real overhead for early-stage teams. Licensing costs are significant. Onboarding time is measured in weeks, not hours. The configuration required to make them useful—module structure, attribute schemas, baseline policies—presupposes organizational decisions that a pre-product startup hasn’t made yet.

This is the gap that tools like Flow Engineering are designed to fill. Flow Engineering is an AI-native requirements management platform built for hardware and systems engineering teams. Rather than requiring teams to define a rigid document hierarchy before they can start capturing requirements, it supports graph-based modeling of requirements and their relationships from the first day of use. Design inputs can be linked to user needs, to system requirements, to design outputs, and to rationale, incrementally, as that information becomes available.

For a medical device startup specifically, this matters because the DHF’s traceability structure—user needs to design inputs to design outputs to verification evidence—maps naturally to a requirements graph. Capturing that graph incrementally, from early clinical concept through final device specification, means the DHF is assembled from genuine design history rather than reconstructed from it. Flow Engineering also supports the kind of rationale capture that makes early-stage decisions legible to reviewers months or years later, which is the actual risk medical device startups face when they delay structured requirements capture.

The relevant limitation is scope: Flow Engineering is focused on requirements and systems architecture. It is not a full quality management system. Medical device companies will still need separate processes for CAPA, supplier management, and production records. For startups in early development, that is not a limiting factor—it is appropriate sequencing.

Practical Starting Points for Pre-Product Teams

You don’t need a complete product specification to begin. You need a minimal viable requirements structure that captures decisions as they are made.

Start with intended use and indications for use. These are the top of the design input hierarchy. They will change, but capturing the current version—and the rationale for it—gives you something to trace everything else against. Even a one-paragraph intended use statement, versioned and dated, is better than nothing.

Capture design inputs when they are generated, not when they are finalized. “Finalized” is a fiction at early stage. Requirements evolve. The discipline is not about having final requirements early; it is about having a record of what you believed at each point and why.

Link every design input to a source. Sources include user needs (from clinical research, KOL conversations, competitive analysis), regulatory requirements (applicable standards, predicate device characteristics, FDA guidance), and technical constraints (component availability, manufacturing process limits, cost-of-goods targets). A requirement without a source is a requirement without a rationale, and a rationale you can’t explain is a design input FDA will question.

Treat your requirements tool as a design communication tool, not just a documentation tool. The most immediate value for a small team is not regulatory—it is reducing the ambiguity that causes engineers to build the wrong thing. A well-maintained requirements structure tells every team member what the device is supposed to do, why, and what constraints are binding. That has compounding value throughout development regardless of your submission timeline.

Honest Assessment

If you are a medical device startup and you are not using a requirements management tool, the question is not whether it will cost you—it will. The question is when you pay: incrementally, in the small discipline of capturing decisions as you make them, or in a lump sum, during submission preparation, when you are under time pressure and the gaps in your design history are visible to reviewers.

Early-stage product ambiguity is real, but it is not an argument against requirements capture. It is an argument for capturing requirements in a tool that can accommodate change without losing history. The FDA does not expect a startup to have had perfect foresight. It expects a startup to have had a disciplined process, documented from the beginning. Those are different requirements, and only the second one is achievable.

The cost of a structured requirements tool at pre-product stage is measured in hours per week. The cost of retroactive design history reconstruction during a 510(k) submission is measured in months. That is the calculation. Start capturing now.