How to ship a Class II medical device app and survive FDA review

Most mobile engineers will go an entire career without their code being read by a federal regulator. I'm not one of them.

I spent about two years as the Android architect on a connected diabetes platform — a Bluetooth insulin-tracking system that paired a smart button and a companion app, operating together as a Class II Software as a Medical Device under FDA jurisdiction. It cleared 510(k) review (K212217) in 2022. Here's the thing nobody tells you before you start: the app was the easy part.

Let me explain what I mean.

"Software as a Medical Device" is a legal category, not a feature set

When software does something a doctor or a device used to do — track a dose, flag a reading, inform a treatment decision — the FDA treats it as a medical device. Not "an app that happens to be in healthcare." A device. Class II is the middle risk tier, and it's where most connected-health mobile products land: not life-support-critical, but not a step counter either. Insulin dosing is squarely in it.

The moment your software is a device, a second product appears next to the one your users see. Your users get an app. The FDA gets an auditable artifact: a paper trail that explains every decision you made, why you made it, and how you verified it does what you claim. Both products ship. Only one of them has a UI.

That second product is the one teams underestimate.

The deliverable is the documentation

On a normal mobile project, the code is the deliverable and the docs are a courtesy. On a Class II SaMD project, that's inverted. The documentation is the deliverable, and the code is one of its supporting exhibits.

What that means in practice:

• Every requirement traces to a verification. A reviewer can pick any claim your software makes — "the app records the dose within N seconds of the button press" — and walk a documented line from that requirement, to the design that implements it, to the test that proves it, to the result. If that line breaks anywhere, you have a finding.
• Every change has a reason on the record. You don't just refactor because the code is ugly. In a regulated build, a change to anything in the device's scope carries a controlled rationale. "We cleaned it up" is not an answer a reviewer accepts.
• Architecture decisions are documented before they're convenient to document. The temptation on any project is to write the design doc after the code works. Under audit, that's backwards and it shows. The decision record has to be a real artifact made at decision time, not a reconstruction.

None of this is exotic engineering. It's discipline — the same discipline good teams claim to have and most quietly skip under deadline. The difference is that on a medical device, skipping it isn't technical debt you pay back later. It's a gap a regulator finds.

Why this is genuinely hard for mobile teams

Mobile culture optimizes for speed and iteration: ship, measure, fix, ship again. That instinct is an asset almost everywhere — and a liability the day your software becomes a device. The reflexes that make you fast in a consumer app are the exact reflexes that produce audit gaps:

• Velocity over traceability. A fast team merges first and documents never. A compliant team can't merge a change inside the device's scope without the paper that justifies it. You have to build the traceability into the cadence, not bolt it on before submission — by then it's archaeology.
• "Good enough" testing. Consumer QA is risk-weighted by user pain. Device verification is risk-weighted by patient harm, and the analysis that decides what to test is itself a documented artifact. You don't get to decide a test wasn't worth writing; you have to document why.
• The codebase as the source of truth. In a normal project, if you want to know what the system does, you read the code. Under audit, the code and the documentation have to agree, and when they drift, the drift is the problem you have to explain.

The teams that struggle aren't bad engineers. They're good engineers running the wrong playbook for the regime they're suddenly in.

What the discipline actually looks like once you've shipped through it

I managed an offshore Android team of ten-plus engineers across a 24-hour development cycle on this platform — onshore architecture and decisions handed off at the end of each day, offshore continuation overnight, integration reviewed the next morning. That structure only works under regulatory constraint if the interfaces and the patterns are documented well enough that people in a different time zone can extend the system without you in the room. The audit-trail discipline and the distributed-team discipline turned out to be the same discipline. The documentation that satisfies a reviewer is the same documentation that lets a team you can't see build against your architecture without drifting from it.

That's the part I didn't expect going in, and it's the part I'd tell any team to internalize: the regulatory rigor isn't a tax on the engineering. Past a certain point it is the engineering. The audit trail forces you to know your own system precisely — what every component does, why it's there, how you know it works. A team that can survive FDA review is a team that genuinely understands what it built. Most teams only think they do.

If you're about to walk into this

A few things I'd want someone to tell me before my first Class II build:

1. Decide what's in the device's scope on day one, and guard the boundary. Everything inside it inherits the documentation burden. A clean boundary is the single biggest lever on how much of that burden you carry.
2. Make the audit trail a build-time habit, not a submission-time sprint. Traceability you generate as you go is cheap. Traceability you reconstruct under a deadline is the most expensive code you'll ever not write.
3. Treat your documentation like a product, because it is one. It has a reader (the reviewer), a quality bar, and a release. Resourcing it like an afterthought is how clearances slip.
4. Get someone in the room who's done it. Not for the architecture — your team can build the app. For the regime. The expensive mistakes are the ones you don't know are mistakes until a reviewer points at them.

The clearance landed. The platform reached the market. And the thing I carry out of it isn't the architecture diagram — it's the habit of building software I could hand to a stranger, with a straight face, and say: here's exactly what it does, here's why, and here's how I know.

That habit is useful well beyond medical devices. But medical devices are where you find out whether you actually have it.

Mohamed Alborati was the Android architect on Eli Lilly's Tempo connected diabetes platform (Class II SaMD, FDA 510(k) K212217), contracted through Deloitte. Read the case study →