Why Some Digital Health Products Last and Most Quietly Fade

Digital health products last when three things hold at once: clinicians trust them, evidence backs them, and they fit the work people already do without asking for heroics. Take away any one and the tool fades, usually not in a dramatic failure but in a slow drift back to the old way of working. The graveyard of health technology is not full of products that did not work. It is full of products that worked in a demo and then could not survive a Tuesday in a real clinic.

I have spent years on both sides of this, building an AI clinical decision-support system for type 2 diabetes and co-founding a company around an AI symptom checker. The pattern repeats with almost boring reliability. What endures is rarely the cleverest model. It is the product that a busy clinician keeps choosing on the days when nobody is watching.

What makes a digital health product actually endure?

Endurance is not adoption. A tool can be installed across a whole health system and still be dead, opened once during onboarding and never again. The honest measure is whether people reach for it unprompted three months after the launch excitement has worn off, and whether they would notice if you took it away.

Here is a definition I find useful. A durable digital health product is one whose value survives contact with ordinary conditions: an interrupted clinician, an atypical patient, a slow network, a skeptical colleague, and a budget review eighteen months later. Each of those is a small test. Products that fade tend to pass the demo and fail the ordinary day. Products that last are built, from the start, for the ordinary day.

Why does trust matter more than features in clinical software?

Because a clinician who does not trust a tool will route around it, and a tool that gets routed around might as well not exist. Trust is the precondition for use, and it is earned slowly and lost quickly.

Trust in clinical software is concrete, not a mood. It comes from a few things a clinician can feel. The output has to be legible, meaning the user can see roughly why the tool said what it said, so they can agree or override with their own judgment intact. The tool has to behave the same way today as it did yesterday, because unpredictability reads as danger. And it has to know its own limits, declining to answer when the case falls outside what it was built for rather than producing a confident output on a patient it was never meant to see.

A common trap is treating trust as a communications problem, something to be fixed with a better onboarding video or a friendlier tone. It is not. Trust is a property of how the product behaves under pressure. You cannot message your way past a tool that gave one wrong-feeling answer at the wrong moment, because the clinician carries the liability and the relationship with the patient, and they will protect both by quietly closing the tab.

How does evidence keep a product alive over time?

Evidence is what lets trust outlast the founder's enthusiasm. Early on, a product runs on the credibility of the people who made it and the warmth of the pitch. That credit expires. What replaces it, if anything does, is a body of evidence that the tool does what it claims for the patients it claims to help.

When we built EASY Diabetes, we framed it around a falsifiable claim: support clinicians managing type 2 diabetes so that outcomes improve and the workflow gets lighter. That framing is what made a real test possible. The EASY-1 randomized controlled trial (NCT03258268) was a multi-clinic study that evaluated the tool against standard of care. What mattered to me was not any single result but the fact that we put the claim to a test that could have gone either way. A claim that took a genuine risk and survived is worth more, years later, than a hundred testimonials.

This is educational content about how products are built and evaluated, not medical advice, and anyone making decisions about their own diabetes care should talk with their own clinician.

Evidence also has to keep coming. A trial is a snapshot of a moment, and the world it measured keeps moving. Populations shift, practice patterns change, and a model trained on one era of data slowly grows stale against the next. Durable products treat evidence as a habit rather than a launch event, watching their own performance after release and being honest when reality starts to diverge from the original claim. The willingness to keep checking is itself a signal of seriousness.

Why do good products still fail to fit real clinical work?

Because the clinic is not a neutral container that a tool gets dropped into. It is a dense web of habits, handoffs, and time pressure, and a new tool either dissolves into that web or sits on top of it as friction. Most fade because they add a step.

Consider two tools that do the same clinical job. The first asks the clinician to open a separate window, re-enter data the system already has, wait, read a screen, and then transcribe the result back into the record. The second surfaces its suggestion inside the work the clinician was already doing, at the moment the decision is being made, in language that matches how they think. On paper these tools have identical capability. In practice the first one is gone within a month and the second one becomes invisible in the good way, the way a tool you stop noticing because it has become part of how you work.

Fit is mostly about respecting the clinician's attention and time, which are the scarcest resources in medicine. A tool that saves thirty seconds of thinking but costs ninety seconds of clicking is a net loss, no matter how good its underlying model. The hardest engineering in this field is often not the algorithm. It is the unglamorous work of removing every step that does not have to be there, so that doing the right thing becomes the path of least resistance.

What does fading actually look like from the inside?

It rarely looks like rejection. It looks like polite neglect. The tool stays installed, the dashboards still report logins from the mandatory training, and the quarterly review shows green. Underneath, the people it was built for have gone back to what they did before, because the old way fit their day and the new way asked them to bend their day around it.

This is why early enthusiasm is such an unreliable guide. The pilot clinic is staffed by volunteers who want the thing to succeed, supported by the team, watched closely. None of those conditions survive the rollout. A product that only works when someone is championing it has not been validated. It has been propped up. The real question is what happens in the clinic that did not ask for the tool, on the week the champion is on leave.

How do you build a digital health product that lasts?

You build for the ordinary day from the first sprint, and you let that discipline shape every other choice. Decide in one sentence what you are claiming and for whom, then treat that claim as the thing you owe evidence to. Design the output so a clinician can see enough of the reasoning to trust or overrule it. Earn the right to interrupt someone's attention by being faster than the workaround you are replacing, not just smarter. And plan for the product's life after launch, because the version of trust that lasts is the one you keep re-earning.

I have been lucky to see what recognition looks like for work that took this seriously, and I have also watched promising tools fade for want of fit. The difference is almost never talent or ambition, both of which are abundant in this field. It is whether the team fell in love with the demo or with the Tuesday. The products that last are the ones built by people who chose the Tuesday, and who would still want the tool in the room if the patient were someone they loved.