How community-based technology solutions can be sustainable

Most community technology projects are not killed by the technology. They are killed by the second year, when the pilot funding ends, the people who built it move on, and nobody local has either the money or the skill to keep it running.

We think about sustainability as four separate problems, because they have four different answers.

Who decides what it is for

A tool that a community did not choose does not survive contact with the community’s actual priorities. Autonomy over which problems get worked on has to sit with the people affected, not with whoever is funding the pilot. This sounds obvious and is routinely ignored, because a funder with a theme and a deadline is easier to satisfy than a village with its own list.

In RachchaBanda this is explicit: the panchayat decides which issues go into the system. If the answer to the first question is always supplied from outside, the rest of the design does not matter.

What it costs to run, and who pays

Grant-funded infrastructure quietly assumes a second grant. That is not a plan.

The costs that actually recur are small and unglamorous — hosting or local compute, electricity, device replacement, someone’s time. They have to be payable from money the institution already controls: local government revenue, local taxes, and where a data collective exists, revenue from the community’s own data on terms the community set. If the running cost cannot be met from sources the community already has, the project has an end date whether or not anyone has written it down.

Who maintains it

The hardest thing to devolve is not the software but the ability to fix it. A local talent pool is a deliverable, not a nice-to-have, and it takes as long to build as the system does. Training the officials who will operate the thing has to be budgeted as a line item, repeated, and repeated again after staff turn over.

Open-sourcing the codebase matters here for a practical reason more than an ideological one: it is the difference between a community being able to hire somebody else to maintain their system and being locked to whoever built it.

Whether people get anything back for the time they give

Community participation is unpaid work, and the people whose voices are most missing — peasant farmers, labourers, women running households — are the ones with the least time to donate. Designing indirect incentives for that time is part of the system design, not an afterthought for the field team.

The honest version

A project is sustainable when the community could carry on without us and would choose to. Everything above is a way of asking whether that is true yet. We do not think a periodic audit-and-improve cycle is optional either — the answer changes as officials rotate, funding shifts and the problems themselves move on.