If it doesn't run on 2G, it doesn't ship
We have a rule on the product team that sounds almost old-fashioned: if a feature doesn't work on a low-end Android phone, on a patchy 2G or 3G connection, it doesn't ship.
We have a rule on the product team that sounds almost old-fashioned: if a feature doesn't work on a low-end Android phone, on a patchy 2G or 3G connection, it doesn't ship. Not "ships with a note," not "ships and we'll fix it later." It doesn't ship.
It would be easy to treat that as a nice-to-have, an accessibility gesture we make ourselves feel good about. It isn't. It's closer to a survival rule for building healthcare products in the markets we actually operate in.
The customer who matters most is the one on the worst connection
It's tempting, when you're building product, to test on whatever's on your own desk , a recent phone, fast office wifi, a strong signal. That's precisely the customer HomeRx and Pharvios are least worried about. The pharmacist reconciling stock at the end of a long day in a shop with unreliable power. The customer trying to order medicine from a part of town where 4G is aspirational. The clinic running Heeavo on a shared device that's a few years old. If a product only works well under ideal conditions, it's quietly excluding the exact people it was built to serve, and doing it invisibly , because the people it fails are the least likely to be in a position to complain about it.
What "runs on 2G" actually forces you to do
This isn't really about a network generation. 2G is a proxy , a stand-in for a whole set of disciplines that good products in this market need regardless of connection speed: pages that load in a reasonable time with a fraction of the bandwidth people in other markets take for granted; screens that don't fall over when a request times out or a connection drops mid-transaction; flows that assume interruption is normal, not exceptional, and recover gracefully instead of losing someone's work. Pharvios is the clearest example of this in practice: a pharmacist can record a sale with no network at all, or in a low-network area, and the transaction is captured locally and synced the moment a connection is available. Reconciliation doesn't wait for a good signal , it just picks up where it left off.
None of that is exciting to build. It rarely shows up in a product demo, because demos happen on good wifi. But it's the difference between a product that works for the market we're actually in and one that only works in the conditions we happen to be pitching in.
The discipline pays off even where the network is good
Here's the part that surprised us: building for the worst connection doesn't just help the customers on the worst connection. A flow that's been forced to be lean, resilient, and fast under bad conditions is faster and more reliable for everyone, including the customer on a strong connection in a major city. Constraints that look like a tax on the product team usually turn out to be a forcing function for better engineering , the same way designing for a small screen tends to produce a clearer product than designing for a large one first and shrinking it down.
Why we treat this as non-negotiable rather than aspirational
It would be easy to let "works on 2G" slide into "works on 2G when we have time," the way a lot of good intentions quietly become optional on
ce a deadline is close. We've deliberately made it a shipping gate instead , something a feature has to pass, not something we retrofit if it turns out to matter. Every feature goes through network throttling in QA before it ships, tested under the conditions our worst-connected customers actually face, not the conditions of an office on fibre.
What this says about who we're actually building for
A rule like this is a statement of priorities as much as an engineering practice. The customer on the cheapest phone and the shakiest signal isn’t an edge case; they're the default user we design for first. Everyone else is the easy case. Build for the hard case, and the easy case takes care of itself. Build for the easy case first, and the hard case, which, in the markets we serve, is most people, never quite gets served at all.
See it running in the field: [Book a Pharvios demo → https://pharvios.com/