I asked a room full of developers a simple question: What do we want as developers?
The two biggest words on the screen were money and learning. But in the background, another common theme kept showing up: building reliable systems.
Then I asked the same room a second question: What do we, as developers, think NGOs want?. The answers were things like simple solutions, accessible systems, and someone to solve their problem.
I put both word clouds side by side and said nothing for a few seconds, a deliberate pause to let the gap sink in
That gap is where our work actually happens. Look a little closer, though, and you can see a bridge: We said we want to build systems which work and while our idea of what NGOs want was solution that works
I started my career on similar lines — build systems that work and learn new things. Five years in the social sector have taught me the bridge is shorter than it looks.
Dev Sprint in Kochi
We spent a week in Kochi for a Tech4Dev dev sprint, bringing together developers, product, and design teams. As the team has grown, sprints have become more team-specific, with fewer chances to work across products or spend time together in person. This sprint was a chance to change that: one week of working side by side, sharing ideas, and experimenting with AI.
In the AI era, strong collaboration between product, design, and engineering matters more than ever
So the week was built for it. Presentations, working sessions, exchanging ideas. We also worked out of Aikyam Space in Fort Kochi — a free community space run for changemakers—and we are grateful to them for sharing it with us. We had Vivek, who helps run Aikyam Space, and two NGOs who use that space gave short talks about what they do. Thudippu Dance Foundation runs an arts school and community space in Kochi on a sliding-scale fee model, so that cost never decides who gets to learn dance. Olimalar Foundation works with young people in Ernakulam on education and environmental awareness, under the line “illuminating young minds, nurturing communities”.
I gave three presentations that week, but my favourite was the one about what I’ve learned from working with NGOs over the past five years. Thanks to Lobo for pushing me, in his own way, to give this session.
The problem every NGO brings us
After the initial Mentimeter word cloud, I started the session with something concrete: an NGO running a chatbot on Glific.
Most NGOs that run a bot arrive at the same place. They have documents specific to their programme, and they want the bot to use AI to answer questions by referencing those documents. At first this looks like a big problem, and like getting it right will take months of work.
But the harder question comes after launch. Once a bot is set up, how do you know it still works tomorrow? That is the question we kept asking ourselves while working closely with a few NGOs
Start with their pain point
Over the years, I’ve worked on and led many features. Our north star for anything we pick is simple: what problem does this solve for an NGO, and how painful is that problem?
Once we identify the problem, we also ask whether it is common enough to be relevant to other NGOs. When working closely with NGOs, almost every problem can feel urgent or critical. Most of them do help in one way or another, but we need to be thoughtful about which ones we choose to solve so we can use our time and effort well.
As a rule, we should prioritise problems that can help multiple NGOs, ideally at least five. This increases the chances that what we build gets adopted and helps us spread our bets across more organizations.
We did not pick this problem because it was interesting. We picked it because it was common across NGOs, so we decided it was worth solving.
The first version of evals was just a script: run it and get a score. The score itself was not the product. From that point on, every change could be measured against it instead of relying on opinion-based judgement.
Empower them to free yourself
Once we find a solution to a problem, we work closely with a few NGOs as beta users to validate it and gather early feedback. That feedback often helps us refine the solution before releasing it more widely.
If the solution works well, the next step is to make it simple enough for NGOs to use on their own. This empowers them to solve the problem independently, while we can focus on the next set of challenges.
In our case, running evaluations still required a developer and took a lot of time. So we brought the process into Kaapi, our AI platform. Now, even NGOs we do not work with directly can run evaluations themselves and check whether their chatbot is working consistently.
Every extra step is a place an NGO can drop off
When building a feature, it’s easy to add a few one-time setup steps and think they won’t be a problem. After spending a lot of time working on the feature, even a 10-step setup can feel simple to us. But it usually isn’t for the NGO using it.
Every extra step is another place where an NGO can drop off. This becomes even more likely when the setup is technical. Most NGOs aren’t tech-savvy, and they shouldn’t have to spend a lot of time understanding technical details just to use a feature.
In our case, Evals 1.0 had a dependency on Langfuse so NGOs could view traces and cost trends. To get there, they had to create an account, create an organisation, create a project, generate API keys, and then add those keys back into our setup.
We also gave them the option to add an LLM as a judge to complement the cosine similarity score. That meant even more setup.
Nothing is obvious, so keep your eyes open
I’ve been on many calls explaining how a feature works and how the UI is set up. During support calls or in-person events, I’ve often said, “Click here to see this,” only to hear, “Oh, I didn’t know that.”
What feels obvious to us may not be obvious to someone seeing the feature for the first time.
The trick is to keep your eyes open. Let people explore the feature, explain what they understand, and take notes. If one person struggles with something, others probably will too. That gives you a chance to simplify it before the next NGO uses it.
This is part of the development cycle too. You build something useful by continuously refining the feature based on how people actually use and understand it.
Earn insights that shape what gets built next
We got a lot of feedback on Evals 1.0, and that feedback pushed us to rethink and improve how evals work. That eventually became Evals 2.0.
This is one of my favourite things about building products at Tech4Dev. Feedback from NGOs tells us that what we are building is actually being used, and it helps us see the same feature from perspectives we may not have considered ourselves.
Working closely with NGOs also helps us understand how they use a feature, what they need next, and what could make their work easier. We should not have a fixed mindset that these product ideas should come only from the product team but we as developers can bring them up during weekly planning too, and we should make these decisions together as a team.
Often, a small enhancement or a better version of an existing feature can be more useful to NGOs in their day-to-day work than adding several new features.
Handhold them — but don’t reduce everything to zero
Often, we have to handhold NGOs and simplify things as much as possible. But we can’t always reduce everything to zero. They also need to learn new things to keep up with how the world is changing, and we take it on ourselves to support that learning through webinars, support calls, and by working closely with them.
This often means spending hours helping them move things forward. Sometimes, it can be repetitive work, like copying and pasting data into a sheet to help them understand how it should be formatted, along with a lot of other non-development work.
These small things eventually help NGOs spend more time on their on-ground programs and less time figuring out the nitty-gritty of making everything work from scratch. It takes patience, but over time, I feel I’m getting better at it. I also saw a great example of this at Glific Connect last week, where the developer had spent six months working closely with an NGO and supporting them through their journey. It was really nice to see that kind of strong, long-term collaboration.
Three meanings of an NGO visit
An NGO visit is not one thing. It can be:
- working closely with them to deliver something in a short time
- pitching them a product that aids their needs
- observing what they do, to understand the sector more
What I’d ask of any developer in this sector
The gap between what we want to build and what the people we build for actually want is real. And that gap gets smaller every time we spend time on their side of it.
That week in Kochi, we worked out of the Aikyam space instead of a hotel conference room. The three talks we heard from NGOs there were not about software at all. I hope that sparked some interest among people who are just starting their careers in this space.
So, visit more NGOs. Understand their side of the problem. Explore the sector beyond the product you are building.
The session also became quite interactive. I invited others from our team to jump in and share their own experiences. Siddhant spoke about working closely with NGOs while consulting them through Dalgo, and Tejas shared his experience of working in the social sector.
He even played a Steve Jobs talk on marketing, which he mentioned used to be played at the Reap Benefit office to inspire new team members.
https://youtu.be/keCwRdbwNQY
He ended with one question for the room: Why are you in this sector?
I could not have planned a better ending to the session, and none of it was planned. I simply opened the floor and let others take the stage.
So, visit more NGO offices and work closely with the people there. And before your next sprint, it is worth having an answer to one question: Why are you in this sector?
