A companion app often starts as a modest line item on a device roadmap: a way to show readings, send reminders, and make the product feel current. Then it grows. Within a year it may be collecting data that clinicians rely on, pushing firmware updates, handling support tickets, and shaping how patients judge the device itself. Many medtech teams discover too late that the app has become part of the product, with all the regulatory, security, and support obligations that come with that.
Building a Companion App: Key Considerations
The good news is that most of the expensive surprises are predictable. Here is what device makers should settle before the first line of app code is written.
1. Decide early whether the app is part of the device
The most consequential question is regulatory: does the app simply display information, or does it analyze data, drive treatment decisions, or control the device? An app that only mirrors readings may be handled very differently from one that calculates a dose, flags an arrhythmia, or changes device settings. FDA guidance on device software functions and mobile medical applications draws these lines, and the agency’s policy on clinical decision support adds another layer for software that makes recommendations.
Getting this wrong in either direction is costly. Treat a regulated function as a “simple app” and you may face rework, delayed clearance, or a recall. Treat every feature as regulated and you may slow the roadmap for no reason. The practical step is to write an intended-use statement for the app on day one, map each planned feature against it, and have regulatory and engineering review that map together. Features that would change the classification can then be deliberately scheduled, separated into a different module, or dropped.
If the app is in scope, it needs to be built under your quality system: design controls, requirements traceability, software verification and validation, and risk management under ISO 14971, with IEC 62304 shaping the software life cycle. Since the FDA’s Quality Management System Regulation aligned the agency’s requirements more closely with ISO 13485, documentation discipline matters even more. It is far cheaper to set up these processes for the app at the start than to reconstruct the evidence later.
2. Treat cybersecurity as a design input, not a test at the end
For connected devices, the companion app is often the most exposed part of the system. It runs on phones you do not control, talks to cloud services, and may relay commands to the device over Bluetooth. FDA’s premarket cybersecurity guidance and the cybersecurity provisions added to the Federal Food, Drug, and Cosmetic Act in 2023 expect manufacturers of “cyber devices” to plan for vulnerability monitoring, provide a software bill of materials, and be able to deliver updates and patches.
In practice that means a few decisions up front:
- Threat-model the whole data path: device, phone, cloud, and any clinician portal or EHR integration.
- Authenticate and encrypt the device-to-app link, and decide what happens when pairing fails or a phone is lost.
- Keep an inventory of third-party libraries and SDKs from the start, so the SBOM is a by-product of the build rather than an archaeology project.
- Plan how you will ship security fixes to the app, the cloud, and device firmware, and how fast.
3. Map the data flows and the privacy rules that apply
Device makers are sometimes surprised to learn that HIPAA may not apply to their app at all, while other rules do. If the app is offered directly to consumers and not on behalf of a covered entity, the FTC’s Health Breach Notification Rule and state consumer health privacy laws, such as Washington’s My Health My Data Act, may govern how data is collected and shared. If the app feeds data to hospitals or physician practices under contract, HIPAA and business associate agreements usually come into play.
Draw the data flow on a single page: what is collected, where it is stored, who can see it, and which third parties (analytics, crash reporting, cloud vendors) touch it. That diagram will drive consent screens, privacy notices, contracts, and security controls. It also makes it much easier to answer hospital security questionnaires later, which can otherwise stall commercial deals.
4. Plan for clinical integration, not just a patient screen
If clinicians are expected to act on app data, think about how the data reaches them. Few physicians will log into a separate portal for one device. Integration with EHRs through HL7 FHIR interfaces, or with remote monitoring platforms that practices already use, often determines whether the data is used at all. It can also determine whether providers can bill for remote monitoring services, which in turn affects how attractive your device is to them.
Decide early which systems you need to connect to, who owns those integrations, and how data will be matched to the right patient. Integration work is rarely the most visible part of a project, but it is often where timelines slip.
5. Budget for life after launch
A companion app is never finished. Apple and Google release major operating system updates every year, Bluetooth stacks change, and phone models multiply. Each change can break pairing or background data sync, and for a regulated app each fix needs to go through your change control process. Teams should budget for ongoing maintenance, a device and OS compatibility matrix, monitoring, and patient support from the start, rather than treating launch as the end of the project.
Support deserves special attention. When a patient’s reading fails to sync, they will call the manufacturer, not the app developer. Clear in-app troubleshooting, good logging, and a support process that can tell device faults from app faults will save real money.
6. Choose and manage a development partner carefully
Many device makers do not have mobile and cloud teams in-house, so they bring in an outside developer. The partner’s experience with regulated software matters more than a polished portfolio of consumer apps. Before signing, ask:
- Have you built software under IEC 62304 and an ISO 13485 quality system, and can you show the documentation, not just the app?
- How do you handle requirements traceability, verification, and risk management, and how will your process plug into ours?
- Who owns the source code, build pipeline, and cloud accounts, and how would a handover work if we part ways?
- How do you manage third-party components and security updates over the product’s life?
Reviewing a shortlist of experienced custom software development companies in the USA against these questions is a useful way to separate teams that understand medtech from those that simply build attractive apps. Whoever you choose, keep design authority and regulatory responsibility in-house; a partner can build to your quality system, but the manufacturer remains accountable for the device.
The bottom line
A companion app can make a device easier to use, generate valuable real-world data, and strengthen a product’s position with clinicians and payers. It can also introduce regulatory scope, security exposure, and support costs that nobody planned for. Settling intended use, cybersecurity, data flows, integration, life-cycle support, and partner selection before development begins is what separates apps that add value to a device from those that become its weakest link.
Editor’s Note: Serhii Tolmach is a Healthcare Software Consultant at WTT Solutions, where he works on software projects for healthcare and medtech organizations, from patient-facing apps to EHR integrations.