Technology for Conservation NGOs: Where to Start Without Wasting Your Grant
Practical guidance for conservation NGOs in India on choosing field data tools and spending limited grant funding where it actually helps.

Conservation organisations rarely have a technology budget. They have a grant with a deliverable attached, and technology is one line inside it. That constraint shapes every good decision you can make — and explains most of the bad ones we are asked to rescue.
The mistake that costs the most
The single most expensive error is commissioning a custom system before the field process is settled. If your data collection protocol is still changing — and in year one it always is — building software around it locks in decisions your researchers have not finished making. Six months later the protocol has moved and the tool has not.
Run the first season on paper or a generic form tool. Let the protocol stabilise. Then build.
Design for the worst phone and no signal
Field data collection in Indian conservation contexts happens on entry-level Android phones, often shared, frequently on their third owner, and almost never in network coverage. A tool that assumes a live connection will silently fail at the exact moment somebody is standing in front of the thing you wanted recorded.
- Offline-first storage with sync when connectivity returns — not an afterthought, the core design
- GPS captured automatically, because manual coordinate entry is where errors enter your dataset
- Photographs compressed on device, since a 12 MP image per record will fill both the phone and the data plan
- Forms that work one-handed, in sunlight, by someone wearing gloves
“If a volunteer with an old phone and no signal cannot complete a record in under two minutes, the tool will quietly stop being used.”
Who owns the data?
This question is worth asking before you sign anything. Conservation datasets have value far beyond the grant that funded them — for future research, for policy, for legal proceedings. If your data lives in a vendor's proprietary system and you cannot export it in a usable form, you have rented your own evidence.
- Insist on full export in an open format — CSV, GeoJSON, or a documented database dump
- Confirm where the data is physically hosted and under whose account
- Establish what happens to the data if the project ends or the vendor disappears
- Keep the ability to hand the system to another developer without a rewrite
Train for turnover
Volunteer and field staff turnover in NGO programmes is high, and institutional memory leaves with them. The Karnataka street-children survey we supported ran with more than 300 registered volunteers; the corridor monitoring programme with WTI spans over 100 users across multiple partner organisations. At that scale, a tool that needs a training session to use is a tool that will be used incorrectly.
Build for someone who has never seen it before and has ten minutes. Write the documentation as a one-page sheet, not a manual. Assume nobody will read either.
Spend the money in the right order
- First, on getting the protocol right — no software fixes a badly designed survey
- Second, on data collection that works offline and reliably
- Third, on storage and export you control
- Last, on dashboards and visualisation — these are the most requested and least urgent
Dashboards demo well to funders. Reliable offline data capture is what produces something worth putting on a dashboard. Fund them in that order and the grant goes considerably further.
