Medical Device Software Development Services: Buyer's Guide

§ 01 · definitions

What counts as medical device software

The law starts with the device. Section 201(h) of the Federal Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h), defines a device as an article intended for diagnosing, curing, mitigating, treating or preventing disease, or for affecting the structure or a function of the body. Software that meets that test can be a device, whatever it runs on.

The FDA names three types of medical device software on its software as a medical device page: software that serves a medical purpose without being part of hardware, software that is integral to a hardware device, and software used to make or maintain a device. The first definition comes from the International Medical Device Regulators Forum, whose working group the FDA chaired.

The 21st Century Cures Act then drew a line. Section 520(o), 21 U.S.C. 360j(o), takes five kinds of software function out of the device definition altogether:

Administrative support for a health care facility: billing, appointment schedules, business analytics, admissions, and practice and inventory management.
A healthy lifestyle, where the function is unrelated to diagnosing, treating or preventing a disease.
Electronic patient records in certified health IT, as long as the function does not interpret or analyze them.
Moving or showing device data: transferring, storing, converting or displaying lab or other device results, unless the function interprets or analyzes them.
Some clinical decision support for professionals, where the software does not process a medical image or signal and the clinician can review the basis of each recommendation independently.

One product can hold both kinds. Under section 520(o)(2), the FDA does not regulate the non-device functions of a product as a device, but it may assess how they affect the device function under review, an approach its 2020 guidance on multiple function device products extends to all such products. A companion app is therefore not one answer: each function gets its own.

Inside the device definition, the FDA says its oversight of device software functions focuses on software that presents a greater risk to patients if it does not work as intended. For some functions that pose minimal risk, it does not expect premarket review.

Six kinds of software you meet around a medical device
Kind	Example	A device?	Who should build it
Software as a medical device	An app that analyzes a heart rhythm recording and flags an abnormal rhythm	Yes	A firm working inside an ISO 13485 quality system
Software in a medical device	The firmware that runs an infusion pump	Yes, as part of the hardware	Your engineering team or a device engineering firm
An app that controls a device	An app acting as the central command for a glucose meter, one of the FDA's own examples	Yes	A firm working inside an ISO 13485 quality system
Device data display	A screen that stores or shows a reading the device already produced, with no analysis	No, under 520(o)(1)(D), until it interprets the data	A software firm, once your regulatory lead documents the function
Administrative support	Ordering, scheduling, inventory, billing and service tickets	No, under 520(o)(1)(A)	Any capable software firm, Digital Heroes included
General wellness	A healthy lifestyle app unrelated to any disease	No, under 520(o)(1)(B)	Any capable software firm, Digital Heroes included

Whether a function is a device is your regulatory lead's call to make and to document, not your developer's. A vendor that tells you on a sales call that your app is not a device has made a legal judgment it does not own.

§ 02 · the FDA path

What the FDA path asks of the software

The FDA sorts devices into three classes by risk, as its classification page explains. Class I carries the lowest risk and general controls, Class II adds special controls, and Class III needs premarket approval. The product classification database usually names the regulation for a device type, which points to the likely route before anyone writes code.

Three premarket routes, with the FDA fees for the year from 1 October 2026
Route	When it applies	Review time the FDA states	Fee, standard (small business)
510(k) premarket notification	The device is substantially equivalent to one already legally marketed, called its predicate	Usually decided within 90 days	$28,653 ($7,163)
De Novo classification request	A novel device with no predicate, where general or special controls are enough, so it lands in Class I or II	A goal of 150 review days, not counting time on hold	$191,020 ($47,755)
Premarket approval (PMA)	Class III devices; the FDA calls it its most stringent marketing application	180 days after filing, under 21 CFR 814.40	$636,732 ($159,183)

Fees from the FDA's device user fee page for 1 October 2026 to 30 September 2027. A device establishment also pays an annual registration fee, $13,785 for the same year.

The documentation set, sized to risk

The FDA's June 2023 guidance on the content of premarket submissions for device software functions replaced its 2005 software guidance and sets two documentation levels. Enhanced applies where a failure or flaw in the software could present a hazardous situation with a probable risk of death or serious injury, judged before any risk controls. Basic applies everywhere else.

The guidance also recommends Enhanced for Class III devices and for devices that form part of a combination product, unless the sponsor justifies Basic in writing. Either way, the submission draws on ten elements:

A statement of the documentation level and the reason for it.
A software description: features, inputs, outputs and hardware platforms.
A risk management file: the plan, the assessment and the report.
A software requirements specification.
System and software architecture diagrams.
A software design specification, submitted at Enhanced and kept in the design history file at Basic.
Development, configuration management and maintenance practices, or a declaration of conformity to IEC 62304.
Testing as part of verification and validation: system level at Basic, plus unit and integration level at Enhanced.
A version history of the tested software.
A list of unresolved software anomalies, each with its impact on safety and effectiveness.

Cybersecurity is part of the submission now

Section 524B of the Act, 21 U.S.C. 360n-2, covers any cyber device: one that includes software, can connect to the internet and could be vulnerable to cyber threats. Its sponsor must submit a plan for postmarket vulnerabilities, keep processes that give reasonable assurance the device is cybersecure, ship updates and patches, and provide a software bill of materials covering commercial, open source and off the shelf components.

The FDA's cybersecurity guidance, reissued in February 2026 to replace the June 2025 version, sets out what it expects to see. For a buyer the practical point is simple: a connected device is not finished at clearance, because someone has to keep patching it afterwards.

The quality system behind it

Since 2 February 2026 the FDA's device quality rule has been the Quality Management System Regulation, which amends 21 CFR Part 820 and incorporates ISO 13485:2016 by reference. The FDA says the change brings its rules in line with other regulators', and that the ISO 13485 framework specifically requires risk management.

Selling in the European Union brings a second rulebook, the Medical Device Regulation, Regulation (EU) 2017/745, with its own classification rules and its own review bodies, so plan for both if Europe is on the roadmap.

§ 03 · standards

Four standards a partner should already work to

Vendor pages in this field list their standards, and a list proves little. Ask instead for the document each standard produces, redacted where a client needs it, and read it. A partner that works to these standards every day will have examples on file.

The four standards, what each governs, and the evidence to ask for
Standard	What it governs	Evidence to ask for
ISO 13485:2016, quality management systems for medical devices	The quality system the whole project runs inside, now the basis of the FDA's own quality rule	A certificate from an accredited registrar whose scope names software design and development, and how your project would sit inside that system or yours
IEC 62304:2006, medical device software life cycle processes	Development planning, requirements, architecture, design, unit and integration testing, release, maintenance, configuration management and problem resolution	A software development plan, a trace from each requirement to its test, and the list of software of unknown provenance (SOUP) with the risk reasoning for each item
ISO 14971:2019, risk management for medical devices	Finding hazards, estimating and controlling risk, and monitoring those controls across the life of the device	A sample risk file showing how one software failure maps to a hazard and to the control that answers it
IEC 62366-1:2015, usability engineering for medical devices	Usability as it bears on safety: the risks of correct use and of use errors	A redacted usability test plan or report from a past project

IEC 62304 also sorts software into three safety classes, as this summary of the standard sets out: Class A where the software cannot contribute to a hazardous situation, Class B where the possible harm is a non-serious injury, and Class C where it is death or serious injury, judged once controls outside the software are counted.

The class decides how much of the process is required, so ask which class each past project was built to. The FDA's 2023 guidance accepts a declaration of conformity to its recognized version of IEC 62304 in place of some development documentation, which makes the standard a working tool rather than a badge.

§ 04 · choosing a partner

Choosing medical device software development services, and checking the claims

Sort the field first. Four kinds of firm answer this search, and only some of them build regulated software.

Four kinds of partner, and where each one fits
Kind of partner	What it does	Fits when	Watch for
Device engineering firm with its own ISO 13485 system	Builds SaMD, software in devices and firmware, often with hardware and verification	You need the regulated software built and documented	Whose quality system governs the project, theirs or yours
Regulatory consultancy	Classification, submission strategy, the 510(k) or De Novo file, audits	You have engineers but need the regulatory route	Some write no code at all, so the build still needs an owner
General software firm, such as Digital Heroes	The non-device layer: portals, ordering, training records, dashboards and support	Your regulatory lead has documented that each function sits outside the device definition	Any drift into analyzing device data moves the work back inside the device
Your own team under your own quality system	Everything, with outside engineers working to your procedures	You are the legal manufacturer and want control of every decision	Outside engineers need training on your procedures before they touch the code

Seven checks to run on a shortlist

Which cleared devices carry its software? Ask for the 510(k) or De Novo numbers and look each one up in the FDA's 510(k) database or De Novo database.
Can the device maker confirm it? A 510(k) record lists the applicant and a correspondent, and a De Novo record the requester and a contact. Neither has a field for the firm that wrote the software, so only the device maker can confirm a vendor's part. Ask to speak to that client.
Whose quality system governs the work? If it is the vendor's, read the ISO 13485 certificate and its scope. If it is yours, ask how the vendor trains its engineers on your procedures.
Which IEC 62304 class has it built to? If your software could contribute to serious injury, ask for a past project at Class C and the plan that went with it.
Who holds the design history file and the code? Write into the contract that the design history file, the repositories and every build record are yours, delivered at each milestone rather than at the end.
How does it track third party software? Ask for a SOUP list with versions and a sample software bill of materials, which section 524B makes a submission item for any cyber device.
Who patches it after clearance, and what will it refuse? Get the postmarket vulnerability process in writing before you sign. A partner that refuses nothing in this field is a risk; our own refusals are in the next section.

§ 05 · our scope

What Digital Heroes builds beside a device, and what it does not

What we build is the software a device company runs around its devices, the kinds of function section 520(o) places outside the device definition. Before any developer, us included, scopes a function, have your regulatory lead document in writing that it is not a device.

What we build

Ordering and resupply portals for clinics, distributors or patients: inventory, orders, invoices and shipment status.
Clinician training records: who has been trained on which product, sessions with attendance, and reminders before a certification lapses.
Field sales and service dashboards: rep schedules, service tickets and loaner kit inventory, with a custom CRM around them.
Patient account portals: sign-in, appointment scheduling, documents and billing.
Support desks and live chat for orders and accounts, never for clinical questions.
Company and product websites, with every device claim approved by your regulatory team before it goes live.
Mobile apps for any of the above, built in React Native for iOS and Android.

What we do not build

Software as a medical device, in any class.
Firmware or any software inside a device.
A function that interprets, analyzes or raises alerts on device data, images or signals.
An app that controls a device or changes its settings.
Clinical decision support of any kind.
FDA submissions, design history files, or the quality system itself.

If another firm already builds your regulated software, we can build the non-device layer beside it, against an interface that your device partner and your regulatory lead define. Because the FDA may still assess how non-device functions affect the device function, have that interface agreed in writing before any build starts.

Where a portal will hold protected health information, the HIPAA rules apply: we sign a business associate agreement with you before any of it moves, and the portal is hosted on AWS, Microsoft Azure or Google Cloud, covered by the business associate agreement that cloud provider signs. An independent firm has reviewed the HIPAA practices we follow.

figure 1 · where Digital Heroes works around a medical device
above the line: software regulated as a device, which we leave to device specialists
below it: the functions section 520(o) excludes, which we build

§ 06 · proof

Builds you can check, none of them a device

None of the work below was built for a device company, and none of it is regulated as a device. It is shown because it is the same kind of software as the layer above: records, roles, schedules and apps. Client builds appear with the client's permission and carry no results figures.

client build · 2026 · planivo.me

Planivo: staff records and rosters for clinics and hospitals

Planivo is ours end to end, the signed-in platform and the public website. The parts closest to this page are its records: who attended which training session, a reminder before each certification runs out, a history of every change, and six roles that are each limited to their own part of the organization. Around them sit rosters by month, leave requests with three approval steps and a speciality clash check, tasks and on-duty screens.

Those training and certification records have the same shape as the records a device company keeps on clinicians trained to use its products.

Planivo home page, the workforce planning platform for clinics and hospitals that Digital Heroes built — The Planivo website. We built it alongside the platform behind the sign-in.

client build · airtrainr.com

AirTrainr: two mobile apps on one stack

AirTrainr's athlete and trainer mobile apps are our build, in React Native and Expo on Supabase. That is the mobile stack we would reach for in a patient account or ordering app beside a device.

our own systems

Live chat and a CRM copilot

The live chat assistant on this site and the AI copilot in our CRM were built in house. They show the support side of the layer above: the assistant handles the opening questions, and any thread can be handed to one of our people.

On Clutch, Digital Heroes is rated 5.0 from 66 verified reviews, checked 13 October 2026.

§ 07 · cost and time

Cost and time: the regulated part and the layer beside it

One public benchmark covers whole devices rather than their software. For a novel high risk therapeutic device, a 2022 study in JAMA Network Open put the mean development cost at $54 million, or $522 million once failed projects and the cost of capital are counted, with 85 percent of that cost in nonclinical development.

That study covers novel Class III devices on the premarket approval route, which is the high end. For device software, the cost drivers are the ones this guide has covered: the documentation level, the IEC 62304 class, unit and integration testing at Enhanced level, usability testing, cybersecurity work and the FDA fee in the table above.

We do not quote regulated work, because we do not do it. For the non-device layer our usual custom software range applies: $40,000 to $150,000 for a focused first version, and $250,000 to $500,000 or more for a complex enterprise platform. Our custom software cost calculator turns your own scope into a planning range.

On time, discovery runs as a separate two-week sprint with its own price. Build sprints of one or two weeks come after it, and each closes with a recorded demo of working code. The FDA's clocks start only when a submission is filed: usually within 90 days for a 510(k), a goal of 150 review days for De Novo, and 180 days for a filed PMA.

§ 08 · working with us

For US device companies: who you would work with

Digital Heroes is headquartered at 1140 Broadway, Suite 704, in New York's NoMad, home to our leadership and our US account directors. No code is written there. Engineering happens mainly in Delhi and Lucknow, with working hours that overlap New York's, and the New York office answers within the same business day, between 9 AM and 6 PM Eastern.

Before past work is shown: after you book a scoping call, both sides sign a one-page mutual NDA, and only then do we walk you through past client work.
After the first call: when the work fits us, a written scope and quote arrive within 48 hours; when it belongs with a device firm, we tell you so on the call.
Who owns it: the repositories and cloud accounts are registered to you from the first sprint, our engineers are collaborators you can remove at any time, and everything written specifically for your project is yours once the final invoice is paid, under our MSA.
Who signs this page: our CTO, Divyansh Singh, who owns the architecture and the technical calls on our custom software builds.

Comparing healthcare vendors more broadly? Our guide to vetting a healthcare software company covers the contracts we sign and the due diligence to run on any of them.

§ 09 · FAQ

Questions buyers ask about device software

The first four are the People also ask questions Google shows for this search, in Google's own wording. The other five come from vendor pages in this field and from a public forum thread asking which companies build software as a medical device.

How much does it cost to develop a medical device?

For a novel high risk therapeutic device, the mean development cost was $54 million, or $522 million counting failed projects and the cost of capital, according to a 2022 study in JAMA Network Open. FDA fees come on top: for the year from 1 October 2026, a 510(k) costs $28,653, a De Novo request $191,020 and a PMA $636,732, with lower small business rates.

How much does it cost to develop a medical app?

It depends first on whether the app is a device. If it is not, such as an ordering, scheduling or account app, it costs what other custom software costs: our range is $40,000 to $150,000 for a focused first version. If it is a device, add the FDA documentation set, verification, cybersecurity work and an FDA fee of $28,653 or more for a 510(k), which is work we refer to device specialists.

What is SDLC in healthcare?

The software development life cycle is the run from planning and requirements through design, building, testing and release to maintenance. For medical device software the usual framework is IEC 62304, which adds risk management, configuration management and problem resolution, with how much is required scaled to the software's safety class. Software outside the device definition follows ordinary practice, plus HIPAA safeguards wherever protected health information is involved.

What are the big 3 medical device companies?

By annual revenue in Medical Design and Outsourcing's 2026 Medtech Big 100, the three largest are Medtronic at about $36.4 billion, Johnson & Johnson MedTech at about $33.8 billion and Medline Industries at about $28.4 billion, with Siemens Healthineers fourth. Some entries count only a company's device segment, so rankings built another way can order them differently.

What is software as a medical device?

It is software intended for one or more medical purposes that performs them without being part of a hardware device, the definition agreed by the International Medical Device Regulators Forum and used on the FDA's SaMD page. An app that analyzes a heart rhythm recording to flag a problem is one example. Software that is not intended for a medical purpose, such as an ordering portal, is not SaMD at all.

What is the difference between SaMD and SiMD?

SaMD stands on its own and can run on a phone, a computer or a server. SiMD, software in a medical device, is integral to the hardware, like the firmware that runs a pump. Both are regulated as devices and both are usually built to IEC 62304; the difference is whether the software is the whole device or one part of it.

How long does it take to bring device software to market?

Development time turns on the safety class and the documentation level, so a fair quote comes after discovery, not before. The FDA's own clocks start once a submission is filed: a 510(k) decision usually within 90 days, a goal of 150 review days for De Novo, and 180 days for a filed PMA under 21 CFR 814.40. Time on hold for an additional information request does not count toward the De Novo goal.

Which companies build regulated device software?

Firms that work under an ISO 13485 quality system and can point to cleared devices carrying their software. Sort a shortlist by kind first, then run the checks in the partner section: look up each claimed device in the FDA's databases, read the certificate scope and call the device maker. Digital Heroes is not one of these firms; we build the non-device layer beside the device.

Does a companion app for a medical device need FDA clearance?

It depends on each function. Ordering, scheduling, billing and account features are administrative support, which section 520(o) takes out of the device definition. An app acting as the central command for a device is one of the FDA's own examples of software it oversees, and a function that interprets device data falls back inside the definition. Your regulatory lead should document the answer for every feature before it is built.

Last reviewed 17 October 2026.

Book a call about the layer beside your device

Book a 30-minute call. Bring the functions you need and whatever your regulatory lead has documented about them, and we will say which we can build and which belong with a device firm instead. You pick the slot yourself, at least five days out.

Book a call

related

More from Divyansh.

Chief Technology Officer · Lucknow · 50 posts on the site

post

Medical Device Software Development Services: a buyer's guide