I joined a NGO in June 2025 to build their tech. Fifteen months on, the parts I’m proudest of aren’t in any repository.
At the dev sprint, I had a lot of conversations with people about the work, and I also gave a small talk on my Fcxo learnings and experience. Thank you to Tejas, for encouraging me to turn that talk into this post.
The brief was clear enough. The organization runs a lot of programs, and each one held its data on its own island. My job was to pull that into one place, build the POCs, and find the places where tech could genuinely help rather than just show up. We did that. Glific flows, Frappe Apps , Dalgo pipelines, dashboards.
But the things I keep coming back to aren’t on that list. Here are five of them.
1. Adapting to the culture
You can’t parachute in. If you’re the person who appears on a call, says “backend” four times and disappears, you stay an outsider, and the work shows it.
Field visits are the fastest cure. Sit face to face. Go to where the problem actually happens and look at it. Ask what, why and how of the people living it, not about them.
Understand the organization first and the relationship follows on its own. After that you’re one of them, not an imposter.
2. Collaboration
Different departments, different use cases. But build enough POCs and you start noticing the same pattern turn up in three different places.That’s the moment to walk across and say: look, we built this over there, this is how the process went. Do you want it here too?
POCs earn their place for a reason that has nothing to do with the demo. They’re what gives people the clarity to sharpen their own problem statement. What comes out of that is stakeholder alignment: communication gets easier, and the problem statement stops being only mine. It becomes a 50/50 partnership.
3. Making the Tech feel like it was theirs
Most of NGOs aren’t technically advanced, and there’s no reason they should be. Dashboard, workflow, code, pipeline. These are alien words here. Every single time, you have to find the simplest way to say the thing.That means putting yourself in their shoes. And sometimes the real work of the day is teaching someone to share their screen on Google Meet, doing it in a way that doesn’t make them feel small, and encouraging them through it.
The first thing that helped was language. I stopped explaining in English and started speaking their local language. The shoulders came down. People asked questions they would never have asked otherwise, and a dashboard explained in the words they use frequently  stopped sounding like something from another world.
The second was confidence. A lot of people had decided, before we’d even started, that this wasn’t for them. I sat next to them and let them click, one small step at a time, until they’d done the whole thing themselves. Once someone has done it once with their own hands, “I can’t do this” turns into “let me try.”
The third was patience. The same question would come up three times, sometimes in the same week, and I answered it the third time the way I did the first. No sigh, no “I already told you.” Handholding only works if it never feels like a favour or a judgement. The moment someone senses frustration, they stop asking, and once they stop asking, they stop learning.
If you don’t believe in what you’re building enough to explain it in their words, and again the third time, nobody else will either.
4. Someone became the tech team
When I arrived, the organization had no tech team at all. There was me and Anto, and that was the whole of it.A couple of months in, a request came up. A girl who had grown up on this campus, in a family that has been part of the organization for years, wanted to intern with us, so she could upskill and become a resource they could keep.
She started on data visualization and built dashboards in Metabase. Then DBT. Then Git, which took a lot of small sessions, just the two of us, working through how to think about repositories and branches.
Every dashboard the organization has today is hers. She handles Glific: onboarding new people in platforms, making changes to the flows. She runs the Dalgo pipeline I built, runs the models, modifies them when they need it.
The skills aren’t the part that gets me, though. Nine months ago she hesitated before speaking and now she’s the one anchoring those conversations. She has become my hands, eyes and legs inside the organization. There is an internal tech team now, and it’s her.
5. A process quietly became a culture
We didn’t set out to write process documentation. We just needed a repeatable way to build a dashboard, so we wrote the steps down – gather the KPIs from stakeholders, draft the design, get the design signed off, build the pipeline, build the dashboard.
What I didn’t expect was what that document did to the conversations around it. The next time someone wanted a dashboard, they already knew the shape of the discussion. Meetings got sharper. The requirements started arriving from their side instead of me having to draw them out.
Then it spread past dashboards. Stakeholder meeting, design document, PRD, implementation. That’s now how anything new starts here, feature or program.
The clearest sign of it is people come to us now with a concept note  already written. I’m no longer the one explaining the process. That isn’t a technical win, but it changed the whole engagement.
