The stack that works in Gurugram fails in Churachandpur.

The studies that built the modern understanding of how a new thing spreads were not done in cities. They were done in farming communities, and the finding that came out of them was awkward for anybody who builds things: what decides whether something spreads is the structure and the infrastructure of the place, far more than how good the thing is.¹ A better product does not win a place that cannot run it.

Which is a polite way of saying that most software is built for the place the builder lives in, and the builder does not know it, because assumptions you have never had reason to question do not feel like assumptions. They feel like how computers work.²

Four assumptions, none of them written down anywhere

One: it is always connected

Not “fast.” Always. Most modern software treats a network as a thing that is simply there, and treats losing it as an error state deserving a message with an exclamation mark.

In a great many places the network is a thing that comes and goes during the day, and being offline is not an error. It is Tuesday afternoon. An application that cannot take an order without a connection has not degraded gracefully in that setting. It has stopped being an application and become a reason to go back to the notebook - and once the notebook comes back out, everything in Paper 5 happens.

Two: it is always powered

A till with a dead battery is a drawer. A router with no power takes the connection with it even where the line is fine. Places with regular outages have a whole layer of practice around this that nobody building software ever sees: the shop knows what to do when the power goes, and the software is usually the only participant that does not.

Three: everybody has a recent phone

The device your staff and customers actually hold is older, cheaper, has less memory, and often has a browser two or three years behind the one you tested on. It may be shared. Storage is nearly full, permanently.

This is the assumption that fails most silently. Nobody reports it. The page is slow, or something does not appear, and the person simply stops using it and does the job another way. You will see that as low adoption and diagnose it as training.

Four: somebody can be there tomorrow

This is the one that changes the architecture rather than the service agreement, and it is the one most often mistaken for a support question.

If the nearest person who can physically touch the machine is a day away - or a week, in a bad season - then anything requiring physical intervention is not a support call. It is an outage of unknown length. Which means the system has to be recoverable by whoever is standing in front of it: a shopkeeper, on a phone, with no training and a customer waiting.

Distance does not change your response time. It changes what you are allowed to build.

What changes in the build

These are design consequences, not preferences. Each one follows from an assumption above.

• Offline is the normal case, not the error case. The work gets recorded on the device and synchronises when it can. Losing the network should change nothing the person in the shop can see.
• Write locally first, always. An order that only exists once a server has confirmed it is an order that can be lost by a network, which is not a thing the person taking it will ever understand or forgive.
• Build for the oldest device you can find, not the newest you own. Go and borrow one from the shop. Test on that. It is the cheapest correction available and almost nobody does it.
• Everything must be recoverable by the person standing there. Restart, re-print, re-sync, resend - visible, named in plain words, safe to press twice. If recovery needs a developer, distance has turned every fault into a multi-day outage.
• Assume the sync will be wrong sometimes, and show it. Say what has not synced and how old it is. A system that hides uncertainty in a place with an unreliable network teaches people to distrust all of it.

Why we are not giving you an uptime figure

The obvious way to end this paper is with a number: uptime here against uptime there, device mix, time-to-fix. We have that data from our own work.

We are not publishing it, and the reason is not modesty. In a small town there are not many businesses running a system like this, and a table of outage figures by region and trade identifies them to anybody local. They did not agree to be a data point in a public paper, and the fact that the figures are anonymised in the file does not make them anonymous to their neighbours.

So: design constraints, no numbers. If we ever publish the comparison, it will be from data gathered for that purpose, with written consent, and the method will say so.