Skip to main content
← Back to blog
Essays4 min read

The Anthropologist's Advantage in Social-Sector AI

Most software for vulnerable people is built by people who never sat with them. I came up the other way, and it shows in what I build.

By Prosocial Coding LLC (Ryan Thomas)

I studied anthropology before I wrote a line of production code, and I spent years in direct services and community education in the domestic violence field before I moved into systems work. For a long time I treated that as a detour, the unusual route I took to get to building software. I have come around to thinking it is the most useful training I have for building software in this sector, and that most of the tools aimed at vulnerable people are missing it.

Look at who builds social-sector technology. A lot of it comes from very capable engineers, often from large tech companies, who start with the technology and look for a problem to point it at. That approach produces elegant tools. It also produces a specific failure: the tool solves a problem the team assumed people had, built cleanly, shipped confidently, and slightly beside the point. The users adapt or they walk away, and the builders rarely find out which.

Anthropology trains you against exactly that mistake. The core discipline is to watch what people do in practice instead of trusting what they say they do, or what you assume they need. You suspend your own model of the situation long enough to see the real one. You pay attention to context and to power, to who has it in a room and who does not. That is a method for figuring out what to build, and it is more rigorous than the requirements doc most software starts from.

The direct services years are the other half. I know what a survivor's conversation about their options feels like, because I have been in the room for it. I know what fills an advocate's day, where the real friction is, and where a piece of software would help versus where it would be one more thing between a worker and the person in front of them. You cannot get that from a discovery call. You get it from having done the work, and it changes every design decision that follows.

Here is where it shows up. When I argue that AI should support the worker rather than talk straight to a survivor, that is not a risk-management position I read somewhere. It comes from knowing how fragile and specific those conversations are, and how badly a confident wrong answer can land. When I treat plain language as a safety feature instead of a nicety, it is because I have watched dense, official language shut people down at the exact moment they needed to understand their choices. When I run "could this harm someone" before anything else, it is because I have seen the harm up close and I am not abstracting about it.

There is research that names the gap from the other direction. A 2026 qualitative study in PLOS One, drawing on interviews with people who had domestic violence experience, found that digital help-seeking tools deliver information and resources well enough but tend to miss the component that makes advocacy work: empathic support. That is the signature of technology designed from the outside. It optimizes the parts you can see in a spec, the resource lists and the routing, and it misses the part you only understand if you have sat with someone in distress. You cannot retrofit that understanding. It has to be in the room while the thing is being designed.

I am not arguing that engineers should not build for this sector, or that a degree in anthropology is the entry ticket. Plenty of excellent builders have neither background. I am arguing that fieldwork-first design is a real advantage and a real form of risk reduction, and that the sector should value it more than it does. A tool built from observed practice is more likely to be adopted, because it fits the work people do. It is less likely to cause harm, because the person who designed it has a concrete picture of who is on the other end. In this work, standing is not decoration on a bio. It is a design input.

The feature list is the easy part. Anyone can ship features. The hard part is knowing which features matter to someone on the worst day of their life, and that knowledge does not come from the technology. It comes from the field. I spent years there before I started building, and it shaped everything I have made since.

Related articles