Build vs Buy: Medical Device Design Control and DHF Software

Buy: where the established products genuinely win

A single product company developing a class II mechanical or electromechanical device with little or no embedded software should buy Greenlight Guru. It was built for exactly that company, it carries design control, risk and document structure aligned to how auditors expect to see them, and it will be operating within weeks rather than quarters. Building an equivalent would cost more and be less familiar to the notified body reviewing it.

Buy Jama Connect or Siemens Polarion if your real difficulty is requirements management at scale and your quality processes already work. Those platforms have mature traceability engines with years of edge case handling in them, and reproducing that is a poor use of development capital.

Buy Matrix Requirements if you are a lean team who needs structure without a heavy implementation, or Ketryx if your specific gap is reconciling a modern software toolchain with a document driven quality system and their model matches how your teams work.

Buy when you are pre submission with one product. The correct priority before a first clearance is getting the device through, not designing an internal platform, and every engineering hour spent on tooling is an hour not spent on verification.

One pricing behaviour to model early. This category is typically licensed per named user, and design control touches more people than quality: systems engineers, software engineers, test engineers, human factors, regulatory and manufacturing. Teams routinely limit seats to control cost, which pushes engineers back into documents and spreadsheets, which recreates the problem the platform was bought to remove. Price the full contributor population or accept that adoption will be partial.

When building the design record is defensible

The build case has two honest shapes, and neither is about wanting nicer software.

The first is portfolio breadth. If you develop an implant, a capital instrument and a mobile application that is itself a regulated device, their design records genuinely differ in structure, evidence type and lifecycle. Forcing all three into one product's template serves none of them, and the workarounds accumulate into a system your own engineers distrust.

The second is software cadence. IEC 62304 expects a software lifecycle with requirements, architecture, unit detail proportionate to safety class, integration and system testing, an anomaly process and configuration management including software of unknown provenance. Your software team works in a repository, an issue tracker and a build pipeline and produces a hundred meaningful changes in the time document control processes one approval. The two common workarounds are both bad: writing documents describing what was already built, which is expensive fiction, or accepting an issue tracker export as evidence and hoping nobody probes the link between an issue key and a requirement. A custom layer treats the toolchain as the source and the quality record as a projection, so the link from requirement to code to test to build is generated rather than asserted.

Add a third condition that is increasingly decisive. Section 524B of the Federal Food, Drug, and Cosmetic Act made a software bill of materials and vulnerability management an explicit premarket expectation for cyber devices. Producing that from your build pipeline for every release, tied to the exact build under review, is straightforward. Assembling it manually before each submission produces a document that is stale by the time it is read.

Two or more of those, plus trace matrix week recurring before every audit and every release, and a build starts to earn its cost.

Comparing licence cost with build cost honestly

Buying. Per user licensing plus implementation plus configuration, with implementation weighted toward getting your existing document structure into the tool. Add the cost of limited seats, which shows up as engineers working outside the system. Add validation of the tool in your environment, which the vendor's package shortens but does not eliminate. Then add the recurring cost you already pay: the two to four weeks of senior quality and engineering time consumed per audit or submission assembling traceability, which in our delivery experience is the number that finally moves companies.

Building. A first release covering versioned requirements with typed bidirectional links, design review records with compliant electronic approval and generated trace views runs roughly $85,000 to $175,000 across 14 to 20 weeks. A full platform adding risk management linkage under ISO 14971, verification and validation evidence capture including automated test ingestion, software lifecycle records with build and bill of materials generation, change impact analysis and design history file package generation runs roughly $230,000 to $550,000 phased across 9 to 16 months.

Then validation of your own platform, which is a named workstream rather than a line item, since it holds quality records and will be examined during audits of your quality system. Budget 15 to 20 percent of build cost annually thereafter, and remember every change to a validated system carries its own evidence obligation, so your maintenance budget buys fewer features than it would elsewhere.

Work that lands on you in year two

Legacy design history files. Migrating historical products is frequently proposed and rarely worth it. Older records were created under different conventions with different identifier schemes, and restructuring them can imply traceability rigour that never existed at the time. The usual right answer is that legacy products stay where they are with a documented boundary, and new development starts in the new system. Deciding that early saves months of low value data movement.

The quality and engineering negotiation. Agreeing what evidence the build pipeline should produce and what a release record must contain is a genuine negotiation between two functions with different incentives, not a requirements interview. It is the most common source of schedule slip in this category, and it cannot be delegated to a developer.

Electronic signature controls. Meeting 21 CFR Part 11 expectations for signature manifestation, record binding, audit trails and access control is real engineering and it is not something to bolt on after the approval workflow exists.

Product lifecycle management boundaries. If you run a PLM system for parts and drawings, keep it, and settle which system owns which field before design begins. That argument during development costs weeks.

Human factors evidence. Usability work under IEC 62366-1 produces session records, formative and summative reports and a use related risk analysis that link back to requirements, and it is consistently the evidence type teams forget to model.

Change one requirement and follow the blast radius

Pick a design input requirement on a live product that is implemented by a risk control and verified by a bench test. Then ask your team to answer four questions from records, and time each one.

• Which user needs does this requirement trace up to, and which design outputs trace down from it?
• Which risk controls depend on it, and where is the evidence that each control's effectiveness was verified?
• If this requirement changed today, which verification activities would need repeating and who would be told?
• Which manufacturing specifications and which registered dossiers would the change touch?

Score it plainly. If all four answers come from a system in under an hour, your current tooling is doing its job. If any answer requires a quality engineer to read revision histories in documents, you have just measured trace matrix week in miniature, and multiplying that by your audit and release frequency gives you an annual cost to compare against a build quote.

Take the same requirement to every vendor demonstration. Ask them to change it in front of you and show what gets flagged. A system that lets a requirement change without marking its verification protocols for review is a document store with better search, and the value in this category is entirely in what happens when something changes.

Getting started without stalling a submission

Start by timing your last submission or audit preparation. Count the senior hours spent assembling traceability rather than improving the device, multiply by your frequency, and put that number next to any quote. Companies that skip this step argue about licence prices and miss the actual cost.

Then decide whether your problem is requirements or lifecycle. If requirements management is the pain and quality processes work, evaluate Jama Connect and Polarion. If document driven quality is throttling a software organisation, look at Ketryx before you consider building anything.

If you buy, price the full contributor population rather than the quality headcount, and ask each vendor for their validation package and what it leaves you to do.

If you build, phase it: versioned requirements with typed links, design review records and generated trace views first, for one active product line. Prove the change flagging works before adding risk linkage, evidence capture and release records. Leave legacy design history files where they are.

On partner selection, ask them to model a requirement change before you sign. Versioned records, typed links and automatic downstream flagging means they understand the problem. A requirements table with a parent identifier column means they do not. Then ask how a commit links to a requirement and what evidence that produces, because a manual mapping spreadsheet rebuilds exactly what you are paying to remove. Digital Heroes works PRD first, so the requirement model, the pipeline evidence contract and the validation approach are approved by quality and engineering together before development. The team is 50 plus people across 2,000 plus delivered projects, holds Fiverr Vetted Pro status, has shipped its own products including Section Vault, and publishes to 2.5 million subscribers on YouTube. India LLP, US LLC and UK LTD entities keep contracting and IP assignment under your own law.

Own the repository and the infrastructure from the first commit. A design history file must remain retrievable for the lifetime of the device, which outlasts any vendor relationship you will sign.

If you would rather someone argued with your brief than agreed with it, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. The document is yours whichever way you go.