Climate Tech in South Asia: Where Software Genuinely Helps

South Asia sits at the sharp end of climate impacts: glacial change in the Himalaya, monsoon variability, heat, and dense populations on floodplains. Technology conversations about this tend to oscillate between grand claims and dismissal. The useful position is narrow and specific: which parts of this problem are actually information problems?

That framing matters because it is testable. If a proposed intervention works by getting the right information to the right person in time to act, software can help and the question is only whether it is built well. If it works by moving earth, changing what gets built where, or changing who is accountable for a decision, software is at best a supporting instrument and the money is better spent elsewhere. Most climate technology pitches fail this test, and failing it quietly is worse than failing it loudly.

Where software has a real role

• Monitoring: sensors, satellite data and the pipelines that make them legible to the people who need them.
• Warning: getting information to the specific people affected, in time, in a language and on a device they actually have.
• Coordination: matching resources to needs during a response, and avoiding two agencies sending the same thing to the same place.
• Verification: independent measurement of whether an intervention did what was claimed.
• Efficiency: reducing energy, water or waste in systems that are already instrumented.
• Records: keeping the observations, the maps and the post-event surveys in a form the next team can read.

Each of those has a concrete South Asian version. Monitoring means river gauges in valleys where the trigger for a flood is upstream of a border and invisible from the affected settlement, a problem set out in why the Bhote Koshi valleys keep flooding. Warning means a siren that wakes a village at 2am and a cell broadcast that does not depend on who installed an app. Coordination means a shared list of what each ward needs after a landslide, updated by the people on the ground rather than compiled in Kathmandu a week later. Verification means being able to check, a year after an embankment was built, whether the settlement behind it flooded less.

Where it does not

Embankments, drainage, building standards, land use, grid capacity and the institutions that enforce any of it. These are the bulk of the problem, they are physical and political, and a well-designed app does not move them. Overstating software's contribution here is not harmless; it redirects attention and funding from the work that matters.

Software makes decisions better informed. It does not pour concrete.

Two specific overclaims are worth naming because they recur. The first is prediction: proposals to forecast landslides, floods or crop failure with machine learning, in regions where the labelled event record is thin and the terrain is unlike anything in the training data. A model fitted to a handful of recorded events in one catchment will be confident and wrong in the next one, and confidence is the dangerous part. The second is the platform: a single system that will coordinate all agencies, which fails not on the software but on the fact that no agency is obliged to use it. Both look excellent in a proposal and both have a poor record in the field.

Adaptation is most of the work, and it is unglamorous

Mitigation gets the attention and the investment. For South Asia specifically, the near-term problem is adaptation: living with a monsoon that arrives in shorter, heavier bursts, with glacial hazards that did not exist a generation ago, with heat that changes when outdoor work is possible. Adaptation work is local, continuous and hard to scale, which is exactly why it attracts less capital than a product that promises the same solution in forty countries.

The software that helps adaptation looks correspondingly modest. Exposure maps that tell a ward office which ground fills first, built from open elevation and settlement data using the method in mapping flood risk with open data. Warning chains that work end to end, described in how flood early-warning systems work. Record keeping that survives staff turnover. None of it demos well and all of it compounds.

Why local teams have an advantage

Climate deployments fail on local specifics: the language a warning is written in, the device an official actually carries, the ward-level relationships that decide whether anyone acts. Teams based in the region know these things without a discovery phase, which is a genuine and undersold advantage in a field crowded with imported solutions.

The specifics are not subtle. Field hardware has to run on solar sized for weeks of monsoon cloud, not for a bench test. Delivery has to assume mid-range Android handsets, prepaid data that runs out, and coverage that disappears in a gorge. Messages have to fit inside a single SMS segment, which for Devanagari is roughly 70 characters rather than 160. Procurement runs on a Nepali fiscal calendar, and the weeks around Dashain and Tihar are not weeks in which anything gets installed or approved. A team that has to learn all of that during an implementation will spend the pilot budget learning it.

Building things that outlast the grant

• Assume the funding ends and design for the operating cost afterwards, then write that cost down explicitly.
• Hand over source, data and documentation to the institution that will run it, before the final payment rather than after.
• Use formats other people can read without your tooling, and publish the schema.
• Keep spare parts and the skills to fit them close to the site rather than in Kathmandu.
• Publish what failed, because the field is currently repeating each other's mistakes at considerable expense.

The recurring cost is the item that decides outcomes and the item that nobody's capital budget covers. A network of field stations needs SIM data, battery replacement, a technician's travel and someone's time. In absolute terms these are small numbers. Institutionally they are difficult, because they are recurrent, unglamorous and easy to defer, and deferring them is how a functioning network becomes a set of dead poles within three years. Anyone proposing a deployment should be asked which line of which budget pays for year three, and should have an answer.

Where the commercial work actually is

For a small firm, the honest opportunity in this space is not a climate product. It is the ordinary engineering underneath: telemetry ingestion that does not lose data when a link drops, systems that keep working offline, geospatial pipelines that are scripted rather than clicked, and public interfaces that survive the one hour a year when everyone opens them at once. That is software development and data work with a specific set of constraints, not a separate discipline, and describing it accurately is more useful to a funder than describing it as innovation.

There is a related commercial angle that is easier to sell and just as real. Businesses in the region carry climate risk directly, through disrupted operations rather than through anything on a balance sheet, and most have no plan for it. Helping a company work out what breaks when the road closes for a week is straightforward, cheap and immediately valuable, and the practical version of it is the checklist in monsoon flood preparedness for Nepali businesses.

The honest framing

Climate work in this region is mostly adaptation, and adaptation is unglamorous, local and continuous. Software's contribution is real, bounded and worth doing properly. Sell it at that size and it holds up. Sell it larger and the first hard monsoon exposes the difference, which is a bad way for a client, a funder or a ward office to learn what the technology was ever capable of.