Rethinking technology funding for nonprofits

In 2025, two nonprofits asked their funders for a technology grant. One was told no. The other was told yes, and it spent more than a year building a tool that the team did not adopt because the programme had ended by the time it was launched. Both nonprofits are now back to maintaining paper registers and copying data into Excel.

The problem here does not rest solely with the funder or the nonprofits. It is that both treat software as something you buy rather than something you run. Technology grants often ask whether the tool can be built. Instead, they should ask:

1. Does the programme really need software to scale?
2. Can the organisation build the product or manage a vendor?
3. Can the organisation pay to keep the system alive once the grant closes?

Skip any one of them and the outcomes are likely to be less than ideal.

I used to think nonprofits couldn’t afford software or that funders would not pay for it. I was wrong about this. I found that the answer doesn’t lie in spending more on technology. It involves spending on it differently and helping the sector make good use of the money it does have.

After working for more than twenty years in corporate software and almost three years in the social sector building reusable open-source software for nonprofits, here is what I have understood about why technology remains underfunded in the social sector and what organisations and funders can do to bridge this gap.

1. Technology belongs in the programme budget

When technology is budgeted under the administrative line, it competes with staff salaries, and it loses. One education nonprofit leader described it to me plainly. “With a flexible funder, line items can be shifted to cover software,” they said. “With a strict one, it is easier to ask for another staff member than to ask for a system. So that is what gets asked for.”

As a result, the sector keeps hiring people to do routine work that software would have done faster. I expressed this to a funder who has worked with both kinds of donors—those that welcomed technology, and those that did not. She noted that nonprofits only ask for what they believe funders are mostly likely to say yes to. Testing the boundary is not worth it when the cost of guessing wrong is the grant itself. Only a few funders, typically those funding technology capacity-building for nonprofits, do provide signals that an honest ask is safe.

Bridgespan has documented the ‘vicious cycle’ where funders expect overheads to stay unrealistically lean. Nonprofits then underreport what they spend on, and the expectation of lean overheads hardens into a norm that nobody believes but everybody follows. Flexibility, therefore, is vital in the programme budget. Where line items can move, the right software gets bought. If not, nothing happens.

2. Someone must choose the right software

I spoke to the CEO of an education nonprofit operating in rural Karnataka. He has a passionate team working with over 40,000 participants. But the organisation cannot be expected to compare MIS platforms, analytics tools, and data collection apps well enough to make the right ask.

Even assuming that they have a funder who is ready to give them a grant of INR 40 lakh to spend on technology, who writes the requirements? Who picks the vendor? Who tells the vendor if they have built the wrong thing? Every hour spent on these tasks takes away from reaching communities. The organisation was not designed or trained for this kind of work.

Nonprofits tend to hear of a technology grant as a mandate to build something new.

What these organisations need is someone in their corner who knows what to ask a vendor and they need this person before the first rupee moves, not after. Funders with in-house technology teams can lend that team’s time to screen requirements and recommend a fit. Funders without one can pay for an independent expert who works for the nonprofit rather than for the grant. This person can look at what the organisation does, where it expects to be in five years, and what it can realistically run, and can then recommend the software it should use and the vendor it can approach. This would cost a fraction of a build but would save a significant amount of money and mistakes at the end.

A tech-forward funder told me that they were willing to pay for a vendor to work with the nonprofit before the grant is approved. This should be the norm rather than the exception.

It gets worse when the money arrives with an assumption attached. “Nonprofits tend to hear of a technology grant as a mandate to build something new,” a nonprofit leader told me. Funders sometimes make this mandate explicit by opting to support something unique. For a niche problem domain, building custom technology is the right call. But this should not be the approach for a data management system, enterprise resource planning (ERP), customer relationship management (CRM), data analytics, or data collection software. These are solved problems. Paying to solve them again buys a more fragile version of something that already works and gives the nonprofit a system only it will ever maintain.

3. Quick and cheaply built systems are difficult to maintain

AI has made building software faster, cheaper, and more accessible, but that cuts the wrong way here. Generating code was never as expensive as running and maintaining the software from year two onwards. Now, a grant that funds a build buys more code, more quickly, for the same money. But this leaves a nonprofit with more of exactly the thing it cannot afford to look after.

Consider a small nonprofit whose sole M&E person used AI to build an app for their dashboards. Six months later, the source data changes shape, and the dashboards quietly start showing last quarter’s numbers. Nobody notices until a report goes out. But who fixes it? You may think AI can do that too, and it certainly can. But repairing a system requires an understanding of why it is built the way it is, and which of several plausible fixes is safe. In this case, however, nobody in the organisation ever held that knowledge.

4. Most nonprofits need the same software

Almost every nonprofit pays for a few common things: technology that collects data from the field, a place to store data, a way to see it, and a way to report it suitably to a specific funder. Strip away the vocabulary of each sector, and the shape underneath is close to identical across hundreds of organisations. What differs is the questions asked of the data, not the plumbing that carries it.

Scalable, well-maintained, open-source software is the obvious response, and the sector has built some of it. What it has not built is a way to pay for it. Tech grants are often tailored to one organisation and one programme cycle, when the tech is meant to serve many organisations over many years. A hosting bill does not equate to a participant count. So the common layer gets funded in fragments, by whoever happens to need it that year, and stays permanently underfunded relative to what depends on it.

5. Shared platforms come with their own problems

Shared software is not free of cost, and a common platform may also not fit everybody perfectly. Migration for organisations is difficult, and for a small team it can consume a season of work that nobody budgeted for. Governance for such platforms can also be hard decisions because a shared roadmap has to be made by someone, and the organisations paying the most tend to be heard most.

Shared platforms can also die. When the funder behind a common tool loses interest, it fails for all nonprofits using it at once. This is a worse outcome than any single abandoned build. A funder who has watched that happen is right to be cautious. But shared software should not be compared to a single system that works. It should be compared to 40 private systems—each at risk if the person maintaining it leaves, and each failing quietly and separately. When common infrastructure is in trouble, everyone can see it, and it is possible to fund the rescue. When a one-off system dies, nobody outside that organisation ever learns why.

Tech grants are often tailored to one organisation and one programme cycle, when the tech is meant to serve many organisations over many years.

To reiterate, more money is not the solution. Instead, both funders and nonprofits must admit what they do not know early on and pay someone who does. A bad decision made quickly is worse than a good one made slowly. In software, the bad decision keeps billing for years.

The ask is clear. Whatever kind of funder you are, put technology in the programme line, and fund the expertise to choose it well before you fund the thing itself. Ask what already exists out there before you pay for something new. Ask for the adoption plan from the nonprofit, because a software nobody uses is not a saving but a liability. And ask who pays to keep it running after the grant runs out.

And to nonprofits: What you need is rarely a new system, but what it offers. Cleaner data, faster reporting, and hours back for your team. Ask for that and let the expertise you fund alongside it decide whether anything needs to be built at all.

—

Know more

• Learn why funders must focus as much on the tech ecosystem as they do on individual projects.
• Learn more about open-source technology in the social sector.