Last week we were invited to a peer learning session hosted by Cisco for their Education-sector grantees, on using AI for software development. Project Tech4Dev is one of Cisco’s grantees, and Siddanth and I got to share our journey with using AI in the Glific and Dalgo engineering teams. The slides are here if you want the full session, but this post is about what I took away from listening to everyone else.
AI is a force multiplier for small organisations
Generally we all know the power of AI and how it is democratising software development. But in the session we got first hand experience of this from Jeremy Schwartz from World Possible. In his session he talked about how he and his team use Claude to build tools and websites to tackle many of their problems. What was fascinating was that he himself is not a developer yet but was saying that he uses Claude as a trainer to teach him how to do things.
He was open about the fact that there were mishaps where AI accidentally deleted files it shouldn’t have yet their conviction in the tool hadn’t reduced. It was inspiring to hear him say that they finished their 80 item long list ideas they had in 6 to 9 months.Â
With great power comes great responsibilities
Yes, AI does unlock abilities for organisations that were just not possible before but it’s not a free lunch. Last month OpenAI reported that its model exploited a zero-day vulnerability in a package registry cache proxy to breach its sandbox environment during an internal evaluation. So organisations who are vibe coding solutions run the risk of exposing themselves to vulnerabilities and malicious actors unless they build with proper security guards in place. Many of the organisations in the non-profit sector have sensitive information of vulnerable people and should be mindful of these risks.
Secure software development practices has never been more important when agents are able to find vulnerabilities faster than ever before this. This is not a reason to panic, but its a useful data point that agents are getting good at finding weaknesses faster than most small teams can think about defending against them. Zero trust habits, which used to be a “mature engineering org” concern , are now relevant to a three person NGO tech team in day one.
If your org is vibe-coding solutions with AI and doesn’t have a technical person, here’s the minimum I’d actually put in place before building anything real:
- Version control from the start. Every change goes through git, no exceptions, even for a solo non-developer builder.
- A separation between what you’re experimenting with and what’s live. Don’t let an AI agent iterate directly on the system real users or real data depend on.
- Secrets never hardcoded, ever. API keys and credentials in a
.envfile or secrets manager, not in a script an AI wrote and you copy-pasted. - A review step — human or AI — before anything touches PII, donor data, or payments. This is the one place where “just ship it” is the wrong instinct even at nonprofit speed.
None of this requires hiring a full engineering team. It requires deciding, before you start, that these are non-negotiable — and possibly a few hours of paid expert time to set them up once.
So DIY, or hire an experts?
I don’t think it has a single answer, but I do think it has a real framework. DIY is fine for: internal tools, prototypes, anything low-stakes where a bug costs you an afternoon, not your donors’ trust.
Get expert help before you build, anything that touches PII or donor data, anything public-facing, anything handling payments, anything where a security failure becomes a reputational failure. Software failures in this sector don’t just cost money, they can permanently damage the trust an org spent years building.
We’re not the experts here either — but we want to help build the bridge
What we found at the session is that a number of organisations are a year behind us, and many have nobody in-house who can tell them which of the above actually matters for their situation. The challenge is also the constantly evolving landscape which makes it very hard for organisations to make long term bets in this.
We are working out what a useful bridge looks like and are running multiple programs like the AI Cohort, DPDP Self Assessment and Fractional CxO to tackle this from multiple angles. But there is more we could do to share our learnings adopting AI for development and within our products so watch out this space. If you are keen to collaborate with us to bridge the AI divide reach out to us!
