Move Fast and Don't Break Patients

A medtech operator’s case for speed.

Slowness is not a virtue.

Just writing this out feels wrong in a healthcare context. As medtech professionals, we are hardwired to associate caution with care, and speed with recklessness. But that framing has done real damage to medtech. It has given founders permission to move slowly out of comfort instead of genuine risk management. It has let weak products calcify behind the shield of compliance. Perhaps most tellingly, it has kept better tools out of patients’ hands for years longer than necessary.

A product that never ships cannot help anyone. A model that never improves may become stale while patients stay underserved. A safety process that blocks every change can preserve theoretical safety while real harm goes unaddressed. But the harm is still occurring in the background, more quietly, more diffusely, in a way that is difficult to observe and remains hidden unless it is purposefully surfaced.

Medtech founders who romanticize caution are not being ethical. They’re being comfortable, and that comfort has a cost.

So let’s start there: speed matters. Fast teams learn faster and discover reality sooner. They avoid spending years perfecting the wrong product. The startup instinct to ship, learn, and iterate is correct, it just needs to be applied more carefully than Silicon Valley typically suggests.

At EpiWatch, we built a seizure detection system. Wearable, real-time, FDA-cleared. The kind of product where the person wearing it has likely already had a seizure alone, and the whole point is that someone shows up when it matters.

Early on, we faced a decision that I think every medtech team eventually faces in some form. We had a modification to how alerts were delivered to caregivers ready for release. The engineering case for shipping was solid. It had been tested internally, and the team was confident. We were moving fast, the way early-stage teams should move, and it was important to the business that we ship the feature quickly.

But a single question kept nagging at me.

What’s the worst case if this breaks?

That question is different from “will this break?” We had tested the feature across a wide array of scenarios and failure modes. I was confident in the architecture. Rather, the question we wanted an answer to was: if it breaks in a way we haven’t seen yet, where does that failure land, and how long would it take us to know?

Here’s the thing about building in medtech that took me time to internalize: it’s not that failure is more likely. It’s that failure travels differently.

In ordinary startup software, the loop is usually tight. You ship, something breaks, users churn, support tickets spike, metrics move, and the team responds. Consumer software has silent failures too: recommendation systems degrade, notifications get ignored, retention drifts for months before anyone understands why. Bad observability is not unique to healthcare. But in most consumer software, the harm, the user, and the signal are close together. The person experiencing the problem is usually the person who generates the signal. They complain. They stop using the product. They leave a review.

In medtech, that loop is structurally different.

Taking the case of EpiWatch, think about what a seizure detection workflow actually is. It’s not one thing, but a chain.

Every link in that chain carries an assumption. The watch is being worn. The sensors are operating. The model is running under the right conditions. The alert is delivered. The phone receives it. The caregiver sees it, understands it, trusts it enough to act.

The product is only as strong as the least reliable link.

And when something fails, the signal doesn’t necessarily come from the person most affected. The patient is the one bearing the risk, but the operational signal, if it comes at all, arrives through a caregiver, a clinician, or potentially an adverse event report. By the time it reaches the company, it has passed through people, settings, and institutions that no dashboard fully captures.

It’s not that medtech failures are magically invisible, or that general consumer products have perfect feedback loops. The difference is that in medtech, by the time some failures become visible, they have already reached the patient. And at that point, the cost may not be recoverable. A bad recommendation can be corrected in the next session. A broken onboarding flow can be patched. A missed seizure alert is different. You can improve the product the next day by adding monitoring, or patching the alerting logic, but you cannot undo the missed alert from the night before.

To be clear, I am not advocating that companies move slowly. I am not saying that we should gate everything and make every change require a committee review and a 30-page risk document.

The mistake I see most medtech startups make is one of two things. Either they adopt full startup mode where everything is an experiment to just ship and see what happens, or they overcorrect into bureaucratic medtech mode where every change triggers a formal process regardless of what the change actually touches. Both are wrong. One leaks risk onto patients. The other leaks time into the void.

The right frame is simpler: classify changes by where failure can travel.

We called it blast radius. Before shipping anything, the question we’d ask is: if this breaks silently, where does it land?

If the answer is internal like a dashboard, a support workflow, an analytics tool, something we’d catch before it touched a user, we moved fast. We iterated quickly without overthinking.

If the answer was anywhere in the chain like a threshold, an alert, a permission state, an onboarding flow that shapes what a caregiver believes the product can do, we slowed down with intention. Add a second reviewer, a staged rollout, a specific sign-off from someone who understands the clinical implications.

The gate doesn’t have to be slow, it just has to exist.

This is the approach we took around the earlier caregiver alerting feature: we put it through a gate. Not a long one, but we mapped the failure modes explicitly, added a staged rollout, and made sure we had monitoring in place before it went to all users.

It shipped. It worked. More importantly, we had the confidence to move quickly on everything else because we knew where our actual constraints were.

That clarity is the thing. When you treat all changes equally, where either everything is risky or nothing is, you lose the ability to make good decisions quickly. You’re either reckless or paralyzed. The blast radius model gives you a third option: a principled way to know where to push and where to hold.

You might read all of this and think: isn’t this just risk management? Apply more scrutiny to riskier changes, less to safer ones. That’s common sense.

You’d be right, it is common sense. Proportional risk management is in every regulatory guidance document and every quality manual ever written.

But almost nobody actually does it. Teams pick a posture and apply it uniformly, either moving everything fast because they’re in startup mode, or moving everything slowly because they’ve built their identity around being careful. The posture becomes the thing being optimized, not the actual risk profile of the change.

The reason to name blast radius explicitly, to make it a question the team asks out loud before every ship, is that without a forcing function, teams default to their posture. The framework is valuable because it forces a question you would otherwise skip.

The best medtech startups move fast where failure is contained, and deliberately where failure reaches the patient. Rather than compromising between speed and safety, they more precisely define both.

Speed without containment is recklessness. Containment without speed is negligence of a quieter kind. The job is to know the difference and build a team that asks the right question before every ship.

If this breaks silently, where does it land?

Start there.