Stop rebuilding the same system

A team running a girls' education programme in Bengaluru and a team running a literacy programme in Delhi face remarkably similar problems. How do we track who we serve? How do we capture outcomes? How do we route communication and report upwards?

Usually, both hire someone to solve it from scratch. A consultant spends weeks in discovery, documents the process, designs a database, trains the team and leaves. It works. Then the knowledge stays locked inside one organisation's systems, and the next nonprofit with the same challenge starts from zero.

Across thousands of organisations, that adds up to enormous waste: duplicated effort, slower digital maturity for the whole sector and a permanent dependence on expensive consulting to move anything forward.

How our own thinking changed

We started in 2020 talking about productivity and software craft. Reduce manual work, build clean systems, implement Zoho well. The instinct was right, but the language could have described any industry.

Over time it became more specific to the sector: nonprofit workflows, impact data, the role of a translator between field reality and technology. Then it moved again. Working inside enough organisations, we kept seeing the same data problems, the same bottlenecks and the same need to turn raw field information into decisions. The logic repeated. Only the context changed.

That shifted the question we ask. We used to ask what custom system an organisation needs. Now we also ask what shared infrastructure would serve many organisations better.

What shared infrastructure looks like

Custom implementation has real value. It builds trust, solves immediate problems and teaches organisations how technology works. But at sector scale it fragments everything into thousands of isolated systems.

Shared infrastructure means standardising the foundation so organisations can spend their customisation budget on what actually differs between them:

• Reusable templates. A volunteer management workflow or programme enrolment form that's been tested once should be adaptable by the next organisation, rather than rebuilt.
• Standard data models. Common entities like participants, sessions and outcomes defined once, well.
• Open playbooks. Documented approaches a nonprofit's own team can follow with light coaching.
• Peer cohorts and office hours. A structured call with organisations running similar programmes often solves a problem faster than a consultant could, and it builds capability rather than dependency.

Open source needs support to be useful

We've explored open-source platforms seriously, including ERPNext, Frappe and Glific. The philosophy fits the sector: organisations owning their infrastructure, reducing vendor dependency and drawing on peer developers.

What we learnt was practical. The tools were technically sound. The learning curve and support around them weren't there yet for resource-constrained teams. When a developer gets stuck, they need active documentation, a responsive community or accessible expertise. A nonprofit that needs its system running next week can't wait on volunteer forums.

A free tool that no one knows how to use isn't free.

That's also why the commercial model matters more than people admit. Adoption needs someone to call when something breaks, someone to sequence change so staff aren't overwhelmed and someone to coach through the first months. Those are real costs. If the sector wants shared infrastructure instead of consultant-heavy custom work, the business model that sustains implementation support has to be part of the conversation. That might mean flat-rate fees for templated solutions, tiered peer-learning communities or social enterprise models that build sustainability into the service design.

AI as practical infrastructure

When our language turned towards AI, we tried hard to keep it tied to specific use cases and field reality.

AI makes sense to us in difficult operating environments. Field teams collecting data in low-connectivity areas. Organisations sitting on qualitative field notes nobody has time to read. Programmes that need to surface context to support a decision. Teams managing more data with fewer people.

In those settings AI is practical infrastructure. It reduces manual data processing so a programme officer can spend time on judgement. It surfaces patterns in field data that would take weeks to find by hand. It lets a small team run analysis it could never otherwise afford. A voice agent can gather rich data from participants for a nonprofit with three staff, without a new data entry hire.

It also has an order. Many organisations need better data practices before they need machine learning. Some need help asking the right questions before they need help automating the answers. AI should arrive after the operating system is in place, as the third job technology does, on top of solid infrastructure and clear process.

Mission, expressed through systems

What connects all of this, from custom builds to templates to AI, is one belief. Technology infrastructure shouldn't become another barrier for organisations serving people.

A custom implementation serves one organisation well. A template can save ten organisations from rebuilding the same workflow. A well-documented open contribution can reach organisations we'll never work with directly. In a sector where resources are finite, that reach matters.

Serious social impact work deserves serious systems. That's what we're building towards.

---

This is the last essay in the series. Start from the beginning with Mission-rich, systems-poor, or read the full pillar essay, Building technology that sticks.