Advice about building versus outsourcing software usually assumes the software is the product. It weighs hourly rates, time zones, and how fast you can hire before the quarter closes. A company that makes a connected medical device is in a different position. The device already holds FDA clearance or a CE mark, and the hardware has shipped. The software around it keeps growing: the companion app, the data pipeline, the cloud back end, the post-market monitoring.
Someone has to own all of it inside a regulated quality system, which turns build-versus-buy into a question of who carries the software lifecycle and keeps the regulatory record straight while they do.
Why Generic Outsourcing Advice Misses a Regulated Device
Generic guides frame the choice as cost savings. On a regulated connected device, three other factors decide it: who owns the regulatory submission and its documentation, how the work fits inside your quality management system, and who sustains the software after launch. Cost still matters, but it is typically not where delivery breaks down.
The failures look like this: a documentation trail that lives in a vendor’s tools instead of your quality system, a safety class assigned without reference to the device risk file, a companion app that released once with no owner for its next security update. These ownership problems surface at an audit or the next submission, when fixing them becomes significantly more expensive.
Three Ways to Staff the Software Work
There are three legitimate ways to close a software shortfall on a regulated device. They differ in what you keep and what you risk.
| Model | Best for | What You Keep | Main Risk |
|---|---|---|---|
| Build in-house | Long-term product ownership and deep device knowledge | Full control and institutional memory | • Slow, costly hiring in a thin regulated-software talent market • Single-person dependencies |
| Full outsourcing | A defined, bounded project with a clear spec | Speed and a vendor’s existing process | • Vendor-management load • Regulatory documentation that can end up outside your walls • Domain knowledge is hard to transfer in enough detail to build the product correctly • Technical knowledge stays with the vendor |
| Staff augmentation | Scaling an existing team while keeping control | Control, QMS ownership, and the audit trail | You still run the quality system and onboard people into it |
Building in-house gives the most control and is the hardest to staff quickly. Full outsourcing moves fastest on bounded work, though it requires you to manage a vendor and contract carefully to ensure you get the documentation you will need later. Staff augmentation adds specialists who work within your quality system for engagement, which suits device makers who hold a clearance and cannot hire quickly enough.
The Non-Embedded Layer Hardware Teams Struggle to Sustain
For device makers, the harder software is seldom the firmware on the device. A hardware-rooted team can handle embedded firmware and the device GUI on its own. The companion mobile app, the sensor and data pipelines, the cloud back end, the physician portal, and a supported software development lifecycle under IEC 62304 keep growing after launch and do not sit naturally with the team that built the hardware. Connected products succeed or fall behind on that non-embedded layer.
That layer also sets what the device is worth. Buyers increasingly pay for the platform around the device, meaning the data, the workflow, and the post-market evidence, more than for the hardware alone. A team that can only maintain the firmware leaves that value uncaptured.
How a Small Team Meets IEC 62304 Without a 200-Person QA Org
IEC 62304 defines three software safety classes, A, B, and C, set by what could happen to the patient if the software contributes to a hazardous situation. That classification decides whether the next year of work goes mostly to documentation or to product, so on a 30-person team it ranks among the most consequential calls a CTO makes. Public guidance is written as though compliance scales with headcount and every team has a large QA organization behind it. A lean team classifies with more care. Rather than picking the highest class the device could plausibly reach and carrying that weight for the whole lifecycle, it uses risk-control measures outside the software, applied through ISO 14971 hazard analysis, to reduce residual risk and lower the assigned class. Hardware interlocks, dose limits enforced in low-level firmware, and supervised-use requirements written into the labeling all count. Class B versus Class C decides whether you verify every module at unit level or verify the architecture at summary level.
Two habits keep the workload from breaking a small team. One is to run IEC 62304 and ISO 14971 as a single loop, so the software risk requirements feed the risk file and the risk-control decisions feed back into classification and verification. Handled as separate workstreams, they generate duplicated documentation that contradicts itself by audit time. The other is to automate the traceability between requirements, design, code, tests, and risk controls, because assembling it by hand from screenshots costs a small team months. IEC 62304 describes lifecycle phases and artifacts, so sprints map onto it cleanly: design inputs and requirements before implementation, verification before integration testing. A team that reads the standard directly, with ISO 14971 in the loop, can keep its documentation lighter than the commentary around it assumes, as long as it has people who have done the work before. That experience is scarce and expensive to hire for a single product.
Who Owns FDA Compliance When the Software is Outsourced?
You do. Responsibility for the regulatory submission and its documentation stays with the manufacturer that holds the clearance, and it cannot be handed to a vendor. The open question is whether your delivery model keeps that documentation inside your quality system or scatters it across someone else’s tools.
Augmentation differs here in practice. Augmented engineers work inside your quality management system, using your design controls, your CAPA, and your traceability, so the artifacts land where you already keep them. Full outsourcing can reach the same place, but only when you contract for QMS-aligned deliverables and have them handed into your system as the work proceeds. Skip that step and you inherit a remediation project the first time an auditor or an acquirer looks for the record. Documentation ownership has to be built into whichever model you pick.
The Run Cost Hardware Teams Underbudget
A mechanical part reaches a final version, but software keeps changing after launch. It runs as a supported process: security patches, operating-system and dependency updates, post-market monitoring, and changes that can trigger a notified-body reassessment or a new marketing submission. Teams with hardware DNA routinely budget software as a one-time build and get caught by the cost of running it.
Regulation now puts that work inside the quality system. Under the QMSR, effective February 2, 2026, the US device quality system is harmonized with ISO 13485, and the February 2026 FDA cybersecurity guidance routes cybersecurity and software maintenance through the QMS instead of keeping it beside the submission. Section 524B, in force since 2023, already makes a machine-readable SBOM a condition of accepting a premarket submission. Lifecycle work is part of staying cleared, so plan the roadmap and the support cost up front. An augmented team is well suited to this maintenance layer, which covers DevSecOps, monitoring, and performance surveillance for any AI feature, ongoing work a founding engineering team should not carry permanently.
A Decision Guide by Stage and Team Size
The right model follows from your stage and team size.
| Your Situation | Sensible Model |
|---|---|
| No software team, pre-clearance | A build-from-scratch partner who owns the SDLC and documentation with you from day one |
| Small team (3–5), already stretched | Augmentation on the non-embedded layer, keeping the core team on the device |
| Post-clearance, scaling the product | Augmentation plus a maintenance and DevSecOps line for the lifecycle work |
For a connected device, time-to-market outweighs hourly rate. Every month of delay costs market position and revenue, and an experienced regulated-software partner starts without a hiring cycle and already knows what the documentation has to look like.
The Takeaway
On a connected device, build-buy-augment comes down to ownership and continuity more than cost per hour. Whichever model you choose, the manufacturer maintains the clearance, documentation, and lifecycle, so the right partner operates within those constraints.
At Intetics, that is the model we run: a dedicated engineering team that works as an extension of yours, inside your quality system, built for the non-embedded layer and the lifecycle work a hardware team cannot sustain alone. We complete your team, we don’t replace it.
Start by working out which of the three situations above you are in.
Not sure whether to build or augment? We will map it against your team, your stage, and your regulatory exposure, with no pitch.
FAQs
Both approaches can work. The deciding factors are regulatory ownership, quality-system integration, and who sustains the software after launch, ahead of hourly cost. In-house gives the most control but is slow to staff. Outsourcing is faster for bounded work but needs careful documentation contracting. Augmentation keeps control while adding capacity.
No. The manufacturer that holds the 510(k), De Novo, PMA, or CE mark keeps responsibility for the submission and its documentation. A vendor can produce the artifacts, but ownership of the clearance stays with stays with manufacturer.
It is the software around the device: companion apps, sensor and data pipelines, cloud back ends, physician portals, and post-market monitoring. The firmware inside the device sits outside this layer. For a hardware-rooted team it is usually the fastest-growing and hardest part to sustain.
No. IEC 62304 specifies lifecycle phases and the artifacts each phase produces, without dictating headcount or a methodology. A small team can meet it by assigning the software safety class correctly, keeping ISO 14971 in the loop, and automating traceability rather than assembling it by hand.
It is adding external engineers who work inside your existing quality management system for the length of an engagement. Capacity scales, while control, design-control ownership, and the audit trail stay with you.
