Building a Well-Mapping App for Bengaluru: Designing for a Community

The Million Wells App is a community map of Bengaluru’s wells, built by Atta Systems as a pro bono development partner for Biome Environmental Trust, that lets contributors record and find the city’s recharge wells in a single shared database. It went live in August 2025 and, as of the Design for Good 2026 Impact Report (August 2026), had mapped 630 wells, supporting Biome’s Million Wells Campaign and its goal of one million recharge wells for the city’s water security. The work falls under UN Sustainable Development Goal 6, Clean Water and Sanitation. Its primary users are the Mannu Vaddars, Bengaluru’s traditional well diggers, working in the field, and building for a community of field practitioners rather than a corporate buyer changes the software at every level.

The credit is shared and specific. Design for Good’s team, Adira Andlay, Rocio Calderon Castro, and Xin Wen, led the service and UI/UX design and the field research, with the Royal College of Art and McKinsey & Company contributing as Design for Good alliance members that supplied and supported the designers; Atta Systems developed, troubleshot, and tested the app. The project is credited in the Design for Good 2026 Impact Report.

The problem behind the app: a city, an aquifer, and a knowledge system

Bengaluru has spent the last decade in a worsening water situation, and Biome Environmental Trust’s Million Wells Campaign is a response that revalues the city’s shallow aquifer rather than reaching only for large infrastructure. Since 2015, the campaign has encouraged residents, institutions, and the government to dig recharge wells that return rainwater to the ground, deliberately framed as a citizen-owned campaign rather than a top-down project.

At the center of it are the Mannu Vaddars, traditional well diggers whose generational expertise underpins much of Bengaluru’s groundwater knowledge. As the city moved to piped water, open wells fell out of use, and this knowledge was sidelined; the campaign has worked to revalue it and restore the well diggers’ livelihoods by integrating their understanding of the shallow aquifer into the city’s water management. Any technology introduced into this context enters an existing, working knowledge system rather than filling a void.

By the early 2020s, the campaign had generated a large and growing body of well data that was becoming hard to maintain across a widening network of contributors. The need was a shared, accessible database that could hold what the community knew and keep it current: a single map of the city’s wells that the people doing the work could actually use. That is the app Atta built.

The constraint that shaped everything: the user is in the field, not the office

The defining constraint of the Million Wells App is that its primary users are practitioners working at well sites, so the design had to fit their working day rather than a manager’s dashboard. This is the opposite of most commercial software, where the person who buys the product and the person who uses it are both office workers with reliable devices, steady connectivity, and time to learn an interface. Here, the tool has to work for someone standing at the edge of a well, on the phone they already own, in the middle of a job.

The design process took this seriously rather than assuming it. Design for Good’s design team worked directly with the well diggers, using questionnaires and field research to understand their day-to-day practices and how they actually use smartphones. The research consistently pointed to one conclusion: any digital tool introduced in this context needs simplicity and clarity above all. Atta then developed the app and user-tested it with the well diggers themselves, which is a more reliable guide than any assumption about how the tool would be used.

That work surfaced four constraints the context imposes on the build:

• Device range. The app has to work on the range of phones people already carry, which is wide and skews to older hardware, so it has to stay light. Device range remains an open challenge: the case study notes that users with older phones cannot yet access all features.
• Connectivity. Field conditions are not an office network, so the app cannot depend on a fast, constant connection. Reliable operation across intermittent connectivity remains a live challenge rather than a solved problem.
• No time to learn. A practitioner will not sit through onboarding, so the core task, recording or finding a well, has to be obvious on first use.
• Varying familiarity. Contributors range from Biome staff to well diggers with varying comfort with apps, so the interface has to work across that range rather than for a single persona.

What changes when you build for a community instead of a buyer

Building for a community changes the software’s priorities, its definition of success, and how it has to be designed, in ways a buyer-driven product rarely has to confront. The differences reach into the architecture and the interface, and getting them right is the actual engineering problem.

Dimension	Buyer-driven software	Community software
Who decides what good is	The buyer, through a specification and a feature list.	The users, through whether they adopt it in the field.
The device	Standardized, often issued and managed.	Whatever people already own, across a wide range.
Connectivity	Assumed: office network or reliable mobile data.	Intermittent, in the field, and not to be relied on.
Learning curve	Training and onboarding are part of the rollout.	The core task must be obvious with no training.
Measure of success	Contract signed, features delivered.	The community keeps using it, and the data stays alive.

Low-friction accessibility decides whether the app gets used

In buyer-driven software, accessibility is often a requirement to satisfy. In community software, it sets the adoption threshold. If a well digger cannot record a well in a few taps, on their own phone, without training, the app has failed regardless of how complete its feature set is. Designing for the widest range of users and conditions is the work, not a constraint on it.

Fast, forgiving capture keeps the database alive

A shared community database is only as good as the data people can get into and out of it. The capture flow has to be quick and forgiving at the point of work, and the map has to make what is already recorded easy to find, so the database stays a living record rather than a form nobody fills in. The design aim is to make contributing easier than not contributing.

Community ownership shapes how the data is held

When a tool enters a community’s existing knowledge system, it has to respect that the knowledge belongs to the community. The Million Wells Campaign is citizen-owned, and a database of the city’s wells is most valuable when it strengthens that ownership rather than extracting the knowledge into someone else’s system. Keeping the community’s data as the community’s is as much a design decision as an ethical one.

Why this is the same discipline as public-sector and international-organization software

The instinct behind the Million Wells App, building for the people who use the system in the conditions they use it, is the same discipline that public-sector and international-organization software demands. Government and international-organization systems are also judged by whether real people can use them, often across a wide range of access, ability, connectivity, and accessibility; there is a scored requirement rather than an optional polish.

Atta has met this before in the same shape. Species+, the app Atta built for the UN Environment Programme World Conservation Monitoring Centre to support the CITES and CMS conventions, is used by officers on the front line of wildlife-trade enforcement: it works offline so it is usable away from a connection, and it is designed for users with varying levels of technical expertise. That is the same problem as a well-mapping app for well diggers: an accessible, offline-capable tool for people doing skilled work in the field, and it is exactly the community-scale, real-world delivery that the public sector and international organizations look for in a software vendor.

FAQ about the Million Wells App

Who are the Mannu Vaddars?

The Mannu Vaddars are Bengaluru’s traditional well diggers, whose generational expertise underpins much of the city’s groundwater knowledge. As the city moved to piped water, open wells fell out of use, and their knowledge was sidelined; Biome’s Million Wells Campaign has worked to revalue it and restore their livelihoods. They are among the primary users the app was designed to serve.

Who designed and who built the Million Wells App?

The two roles were separate. Design for Good’s team, Adira Andlay, Rocio Calderon Castro, and Xin Wen, led the service and UI/UX design and the field research, as part of the Design for Good alliance, which includes the Royal College of Art and McKinsey & Company, who supplied and supported the designers. Atta Systems was the development partner: it developed, troubleshot, and tested the app, including user testing with the well diggers.

What does “pro bono development partner” mean here?

It means Atta Systems built the Million Wells App without charging for the development work, as a contribution to the campaign’s public-good goal, delivered through Design for Good under UN Sustainable Development Goal 6. Atta’s role was engineering: building, troubleshooting, and testing the app that the design team had researched and designed.

Atta Systems builds government and public-sector software, including civic-tech work like the Million Wells App, for the people who use the system in the conditions they use it rather than for a specification on paper.