The last mile is already staffed

There is a persistent assumption in technology-for-development that the constraint is coverage. Build the platform, the thinking goes, and reach follows. In practice the reach already exists. India has more than a million accredited health workers, a school in nearly every habitation, legal-aid clinics in most districts, and agricultural extension officers who know their blocks intimately. The presence is not the problem.

What these people lack is leverage. A health worker who sees two hundred patients at a camp has no way to know which of them came back. A teacher handling four grades cannot be in four places. A paralegal carrying nine hundred matters cannot read every cause list by hand each morning. None of these are knowledge failures. They are throughput failures, and throughput is what software is for.

The reach already exists. What is missing is leverage.

The precedents worth studying share this trait. Crisis mapping in Kenya was built on SMS because that was the device people held, not because text was elegant. Rural vision centres in south India worked because a technician plus a link to an ophthalmologist beats a hospital nobody can travel to. Drone delivery of blood in Rwanda succeeded because it accepted the road network as given and solved the last mile instead.

In each case the technology deliberately did not replace the person on the ground. It removed one constraint that person could not remove alone, and left everything else intact. That is a narrower ambition than most platforms are sold with, and it is the reason these deployments are still running.

This is the design brief we hold ourselves to. If a proposal requires the field team to work differently, be trained extensively, or trust something they cannot inspect, we have probably solved the wrong problem. The good version is invisible: the same person, doing the same work, reaching four times as many people.

What leverage actually looks like in the field

Leverage is rarely a new capability. It is usually the removal of a specific, boring obstacle. A record that survives six hours without a signal. A cause list read automatically instead of by hand at six in the morning. An advisory delivered as a voice call rather than a document nobody can open. Each of these is a small engineering problem and a large operational one.

The test we apply is whether the field worker notices the software at all. If the answer is yes, we have usually added work rather than removed it. The best deployments we have seen are the ones staff describe as simply how the job is done now, with no particular enthusiasm about the tool itself.

Why platform thinking keeps failing here

Platforms assume a homogeneous user, a stable environment and an incentive to log in. Field work offers none of the three. A platform built for eleven districts encounters eleven different registers, three languages, four device generations and a staff turnover rate that makes training a recurring cost rather than a one-time one.

Tools that survive tend to be narrow, embedded in an existing routine, and indifferent to who is holding the phone. They are less impressive in a demonstration and considerably more useful eighteen months later.

Questions this raises