Why Offshore SaMD Projects Fail – It’s Never the Code

Today, that practice generates millions in annual recurring revenue. Every dollar comes from US medical device innovators building connected devices, Software as a Medical Device (SaMD) platforms, and AI diagnostic tools. Growing this business taught me a brutal truth about selling and delivering complex software in a regulated environment: talented engineering teams — teams that are technically brilliant by any normal industry standard — routinely fail on their SaMD project.

The failure is never technical. It is commercial, and it comes down to domain know-how and ecosystem knowledge.

In traditional enterprise software, you ship the code and write the docs later. In the eyes of the FDA, the documentation is the product. When offshore teams treat regulatory rigor as a bureaucratic add-on rather than the core engineering architecture, timelines explode, budgets burn, and client trust evaporates.

Here is the operational reality every engineering team must understand before they touch their first line of SaMD code:

When a US medical device company evaluates and engineering partner, the truth is they aren’t evaluating our software developers; they are evaluating our ability to survive an audit.

The FDA does not read code: they read a Design and Development File. The Traceability Web: every requirement must trace to a design decision, every design decision to a test case, and every test case to a risk control. The Golden Rule: if an engineering activity is not logged within this continuous web of evidence, it legally did not happen. True MedTech engineering partners are defined by the artifact ecosystem they deliver, not just the features they ship.

What this looks like in practice

A single feature — say, a dosage-calculation screen — doesn’t produce one artifact. It produces an entire evidence chain that an auditor can walk in either direction. Example:

Requirement (REQ-014): Display calculated dose within 2 seconds

• Design Decision (DD-031): Client-side calculation with server-side verification
• Test Case (TC-058): Verify dose display latency under load
• Risk Control (RC-009): Timeout fallback prevents stale-dose display

Multiply this one requirement by every requirement in the system, and you have the DHF.

Teams that build this web as they go spend a few extra hours per sprint. Teams that reconstruct it before submission spend months — and the reconstructed version is always weaker, because gaps in the evidence chain are exactly what a reviewer is trained to find.

In standard software, a Failure Mode and Effects Analysis (FMEA) or risk register is treated as administrative paperwork for the compliance team to file. In SaMD, risk management (ISO 14971) dictates your architecture.

• Every software hazard identified must explicitly map to a specific mitigation strategy.
• That mitigation must map to the exact line of code implementing it.
• An automated test must prove that the mitigation cannot be bypassed.

If an engineering team writes features without checking the risk envelope, they are actively building a product that will fail verification.

A hazard log is not a spreadsheet you file away

It’s a live document that dictates sprint priorities. Two typical entries:

Hazard: Incorrect dose calculation — Severity: Critical · Likelihood: Low

• Mitigation: Independent server-side recalculation with a hard bounds check
• Verification: Automated regression suite with 100% branch coverage on the calc module

Hazard: Delayed alarm delivery — Severity: Serious · Likelihood: Medium

• Mitigation: Redundant alert channel with heartbeat monitoring
• Verification: Load test simulating network degradation

Each hazard drives a specific architecture decision and a specific test — not a generic “we tested it” sign-off.

IEC 62304 requires every software item to be classified as Class A, B, or C, based on the severity of harm it could cause. This classification determines your downstream documentation rigor, verification depth, and risk analysis.

The Trap: under time and cost pressure, teams gravitate toward the lowest defensible classification to reduce paperwork.

The Reality: FDA reviewers see this pattern constantly. When a reviewer asks, “Walk me through your rationale for classifying this as Class B,” and your answer doesn’t hold up, you trigger an Additional Information (AI) request.

The Cost: an AI request doesn’t just cost you a form; it costs you months. Every week spent responding to deficiency letters is a week your competitor’s cleared product is gaining market share.

How the three classes actually differ

Class A: No injury or damage to health possible. Baseline design and test records. Examples: wellness trackers, admin/reporting tools.

Class B: Non-serious injury possible. Full unit and integration test evidence, defined coding standards. Examples: diagnostic imaging viewers, dosage calculation aids.

Class C: Death or serious injury possible. Full V&V, detailed design docs, independent code review, unit-level traceability. Examples: closed-loop insulin dosing, arrhythmia detection.

Rigor scales sharply from Class A to Class C. Misjudging this by even one tier reshapes the entire project plan.

Offshore teams often focus purely on whether the code executes flawlessly according to acceptance criteria. In MedTech, human factors are non-negotiable. If a clinician misinterprets a button placement under high stress and administers the wrong dosage, the FDA classifies that as a design failure, not a user error. Building a successful SaMD product requires an obsession with clinical workflows. Engineers must understand why UI constraints exist, or the product will be commercially dead on arrival.

The IEC 62366 process, in order

Use Specification: define the intended users, use environments, and clinical workflows before any screen is designed.

Use-Related Risk Analysis: identify every point where a plausible use error could cause harm, not just where the code could throw an exception.

Formative Evaluation: iterative, low-cost usability testing throughout design to catch confusing interactions early.

Summative (Validation) Testing: structured testing with representative users under realistic stress conditions, mapped directly to the risk analysis.

Skip the first two steps and no amount of summative testing at the end will save the submission — the FDA wants to see the reasoning trail, not just a passing result.

The FDA’s expectations (driven by strict Section 524B mandates) have shifted from reactive patching to proactive design. You cannot build a web application, run a penetration test the week before launch, and call it a day. Winning enterprise trust requires security baked into the foundational architecture:

• Maintaining a live, continuous Software Bill of Materials (SBOM) for open-source dependencies.
• Executing threat modeling at the epic level before code is written.
• Locking down data-at-rest encryption from day one.

What Section 524B actually expects at submission

• Cybersecurity Management Plan: a living plan covering the full product lifecycle, not a one-time assessment.
• SBOM: a machine-readable inventory of every software component, updated as dependencies change.
• Vulnerability disclosure process: a documented, public path for researchers to report issues.
• Patch and update process: a committed cadence for shipping security fixes post-clearance.

These requirements must exist before submission, not be retrofitted after.

This is the root cause underlying all project friction. Your Regulatory Affairs (RA) team says, “traceability matrix,” and your engineering team hears “spreadsheet.” Your RA team says, “software anomaly report,” and your engineering team opens a Jira ticket, closes it, and moves on with their sprint. Neither side is wrong, but they aren’t talking about the same object. This translation failure is why technically excellent software teams produce regulatory packages that fall apart under review. It comes down to domain know-how and ecosystem knowledge, not communication style. It must be addressed on day one — not discovered during a pre-submission audit when it is too late to rebuild your traceability web.

A working glossary — worth pinning to your team wiki

“Traceability Matrix” → Engineering hears “a spreadsheet” → Compliance actually needs legal proof every requirement was verified.

“Software Anomaly Report” → Engineering hears “a Jira ticket” → Compliance actually needs a regulated event requiring root-cause analysis.

“Design History File” → Engineering hears “a project folder” → Compliance actually needs the single audit-ready evidence trail.

“Verification & Validation” → Engineering hears “testing” → Compliance actually needs proof the design is both correct and clinically fit.

Same requirement, described in two professional languages. Share this list with both teams on day one.

There is a particular kind of exhaustion that hits teams right after clearance: the illusion that the hardest part is over. It isn’t. Clearance obliges you to ongoing post-market surveillance: real-world performance monitoring, complaint handling, adverse event reporting, and continuous updates to your risk management file. If you make a significant change to your algorithm or intended use, you may find yourself back at square one filing a new submission. Post-market isn’t a compliance tail; it is a second, quieter, indefinite project running alongside your product roadmap.

What the post-market phase actually includes

Complaint handling: a formal intake and investigation process for every reported issue.

Adverse event reporting: mandatory reporting to the FDA within defined timelines for qualifying events.

Field performance monitoring: ongoing analysis of real-world data against your original risk assumptions.

Risk file updates: every new signal feeds back into the same ISO 14971 risk management file that shaped the original design.

Change control: for AI/ML products, a Predetermined Change Control Plan (PCCP) defines exactly which model updates can ship without a brand-new submission.

Teams that budget engineering time for this phase treat clearance as the midpoint of the project, not the end — because that’s what it actually is.

Building SaMD across borders and time zones is a highly profitable, scalable strategy, but only if you move past the illusion that you are hiring “coders.”

To win in the US MedTech market, you must deploy regulatory engineers whose primary output just happens to execute on a computer. When you align engineering discipline with regulatory reality, you don’t just ship compliant software; you build a predictable, repeatable engine for cross-border growth.

Author: Krishna Kishore P, Head of Global Business | Sales | GTM Strategy