Software that is part of a medical device, or is itself the device, is not built the way other software is built. The difference is not extra testing at the end. It is that the process itself is the regulated artifact: what you decided, why, who approved it, what you tested and what you did when something changed all have to be recorded as you go, because the record is what gets inspected.
The quality system is the product, as far as the regulator is concerned
Device manufacturers in the United States operate under 21 CFR part 820, the quality management system regulation. What that means in practice for a software team is that requirements, design decisions, verification and validation evidence, change control and supplier oversight all have to be maintained as controlled records rather than reconstructed later. An agency that proposes to build first and document afterwards is proposing something you cannot use, and the cost of retrofitting that evidence usually exceeds the cost of the original build.
Classification decides how heavy the work is, and it is not the agency's call
How much process applies depends on what the software does and what happens if it is wrong. That determination drives the whole plan, and it belongs to your regulatory function, not to your development agency. Get it settled before you take fixed price quotes, because a bidder pricing a wellness feature and a bidder pricing a device function are pricing different projects. Any agency that offers to tell you your classification in a sales meeting is telling you something about itself.
If it touches patient data, the Security Rule applies on top
Regulatory approval and privacy obligations are separate stacks and you will usually owe both. Where protected health information is involved, the HIPAA Security Rule's technical safeguards at 45 CFR 164.312 require access control, audit controls, integrity controls, authentication of the person or entity seeking access, and transmission security. These are architectural decisions, so they need to be in the design from the start rather than presented as a hardening phase near launch.
How to tell a medtech agency from a capable general one
Ask which quality management system the work will be performed under and whether it is the agency's or yours, because someone has to own it and the answer changes your obligations. Ask for a sample traceability matrix from previous work, redacted. Ask how it handles a requirement change after verification has begun. A team that has shipped regulated software answers these immediately and in detail; a strong general agency will answer them in principle, which is the distinction you are paying to detect.
Questions people ask about medical device software development services
Can a normal software agency build medical device software?
Only inside a quality management system that satisfies 21 CFR part 820, and someone has to own that system. Plenty of capable general agencies can work within yours; very few bring their own. Establish which arrangement you are buying before comparing prices, because it is the largest single difference between bids.
Does the HIPAA Security Rule apply to our device software?
If it creates, receives, maintains or transmits protected health information on behalf of a covered entity, yes, and the technical safeguards at 45 CFR 164.312 apply: access control, audit controls, integrity, authentication and transmission security. That is separate from and additional to device regulation.
Why are medtech quotes so much higher than ordinary software quotes?
Because the documented process is part of the deliverable. Requirements traceability, verification evidence, controlled change management and supplier oversight are real work, and they do not disappear if nobody quotes them. They simply arrive later as an unbudgeted remediation.