Building Health Apps Where the Network Isn't Reliable: What We Learned From 1.5 Million Users

The World Health Organization adopted its Global Strategy on Digital Health at the World Health Assembly in 2020, defining mHealth as the use of mobile wireless technologies for public health. The strategy is explicit that the aim is strengthening health systems, not adding apps to them.

The research literature on low and middle income countries is consistent on where these projects fail. It is rarely the clinical content. It is equitable access, digital literacy, and the assumption of infrastructure that is not there.

We build in that environment. Pharmapedia Pro, our drug reference application, has passed 1.5 million users. Ward Guide and Gynae Guide teach clinical procedures through simulation. Here is what the constraints taught us.

Assume the network is absent, not slow

The common failure is designing for a slow connection. The real condition is no connection: a basement ward, a rural clinic, a hospital corridor with concrete walls.

A doctor checking a drug interaction while standing next to a patient cannot wait, and cannot come back later. If the answer requires a round trip to a server, the app is useless at the exact moment it matters. Our reference data ships with the application and syncs when it can. This makes releases heavier and updates more complex. It is not negotiable.

Search is the product

We initially built careful navigation: categories, therapeutic classes, a considered hierarchy. Almost nobody used it. Users type a partial drug name, frequently misspelled, often a local brand rather than a generic, and they expect the right answer immediately.

The hierarchy was our mental model of the domain, not the user's task. The user's task is one lookup, under time pressure, in front of a patient. Search that tolerates misspelling and knows local brand names is worth more than any amount of information architecture.

Accuracy is not a feature, it is the entire liability

A consumer app that shows a wrong price is embarrassing. A drug reference that shows a wrong dose is dangerous.

All Pharmapedia content is verified by qualified, registered healthcare professionals. That review is the slowest and most expensive part of the product and it is the part that cannot be compressed. Any development team that treats medical content as data entry has misunderstood what they are building.

This also shapes the release process. A cosmetic bug can wait for the next release. A content error cannot, which means you need a way to push corrections without a full app store cycle.

Simulation beats reading for procedures

Ward Guide and Gynae Guide teach procedures through game-like simulation rather than text. This was not a design flourish. Medical students and paramedics learn procedures by doing them, and the first opportunity to do them is usually on a real patient.

Rehearsal in an app is a poor substitute for supervised practice and a good substitute for nothing at all, which is often the alternative. The measure of success is not time spent in the app. It is whether someone performs the procedure more confidently the first time.

What we would tell anyone starting a health product

Decide early whether you are building a reference tool or a clinical decision support system, because the regulatory and liability position differs sharply and retrofitting is painful.

Budget for clinical review as a permanent running cost, not a launch task. Medicine changes.

Test on the oldest device your users actually own, on no connection, in a corridor. Not on a flagship phone on office wifi.

The WHO framing is right: the goal is a stronger health system, not more software. Most health apps fail because they were built as products first and clinical tools second.

Sources: WHO Global Strategy on Digital Health (adopted 2020, World Health Assembly); peer-reviewed literature on mHealth implementation in low and middle income countries; Encoder Bytes product data.