Nonprofit software
What happens to grant-funded software when the grant ends
Most grants fund the build and nothing after it. Decide early how the software will be operated, transferred or retired.
Grant-funded software has a predictable shape. A funder supports a project for two or three years. The software is built, launched and used. The grant closes. The software keeps running, because software does not stop on a reporting date, and for a while nobody notices that nothing is paying for it.
Then a dependency reaches end of life, or a payment integration changes its API, or the hosting invoice arrives with nobody assigned to approve it. The organization discovers that it owns a system it cannot maintain, holding data it cannot easily move, serving people who now depend on it.
This is avoidable, and it is avoided at the proposal stage rather than at the end.
The failure is slow and looks like success
Nothing breaks on the day the grant closes, which is the difficulty. The decline is gradual enough that no single moment forces a decision.
Content goes stale because the person who updated it was funded by the project. Small faults go unreported because there is no longer anywhere to report them. A security update is skipped because applying it requires a developer and there is no developer. Eighteen months later the system is visibly neglected, the people it serves have quietly stopped relying on it, and the organization is left deciding between an unplanned rebuild and switching the thing off.
The sunk investment then produces its own pressure: the system is kept alive precisely because so much was spent on it, long past the point where that is the right call.
Name the operating cost before the build starts
Every piece of software has a running cost that exists whether or not anyone has budgeted for it. Write it down during the proposal, not during the final report.
| Cost | Typical pattern | Who owns it after the grant |
|---|---|---|
| Hosting, storage and backups | Monthly, grows with use | Needs a named budget line |
| Domain and certificates | Annual, small, easy to lose | Must sit in the organization’s own accounts |
| Dependency and security updates | A few times a year, needs a developer | The most commonly unfunded item |
| Third-party services and licences | Monthly or annual, price rises | Review before each renewal |
| AI or messaging usage | Per use, varies with activity | Needs a cap and an alert |
| Content and member support | Continuous staff time | Often the largest real cost |
| Major modernization | Year five to eight | Plan for it or plan to retire |
Put a realistic annual figure against the total. Funders are more receptive to a three-year sustainment line in the original proposal than to an emergency request two years later, and some will not fund the second conversation at all.
Build for the budget you will actually have
If the honest answer is that the organization will have very little capacity after the grant, that is a design constraint, not a disappointment. It should change what gets built.
Fewer integrations means fewer external APIs that can change under you. Boring, widely used technology has longer support windows and a larger pool of people who can work on it. A managed platform costs more per month and much less in attention. Features that require regular staff curation are features that will decay first — be deliberate about which ones genuinely earn that ongoing effort.
A smaller system that is still running and trusted in year five has delivered more than an ambitious one that was quietly abandoned in year three.
Settle ownership on day one
Ownership is cheap to arrange at the start and expensive to reconstruct later, particularly if the relationship with the original developer has ended.
The domain, DNS, hosting, application accounts and source repository should be registered in the organization’s name, with at least two staff holding access. A departing contractor, a personal email address on the hosting account and an expired domain have ended more grant-funded systems than any technical fault.
Agree what handover includes and treat it as part of acceptance rather than a courtesy: a current deployment guide, credentials transferred properly, known issues written down, and enough documentation for a developer who has never seen the system to make a change safely.
Decide which of the three endings applies
Every grant-funded system reaches one of three outcomes. Choosing deliberately is far better than arriving by default.
Sustain it. The organization keeps operating the system and funds it from core budget, member revenue, a service fee or a subsequent grant. This requires a named budget line, a named owner and a maintenance arrangement — whether that is a support contract, an internal developer or a retainer.
Transfer it. Another organization, a sector body or a consortium takes it on. This works when the software serves a sector rather than one organization, but it has to be arranged while the original team is still available to explain it. A transfer negotiated after the staff have left is usually a rebuild wearing a different name.
Retire it responsibly. Sometimes the right answer is to switch it off. Done properly this means telling the people who use it well in advance, exporting their data in a usable format, giving them somewhere to go, preserving what has to be kept for legal or historical reasons, and keeping the URLs working long enough for the change to propagate. A planned retirement protects the organization’s relationships; an unplanned one damages them.
Decide which ending is intended before the build, and record the conditions that would move you from one to another.
What to include in the proposal
A funder reading a proposal with a sustainment plan sees an applicant who has thought past the launch event, and those are rare.
Include the annual operating cost and where it will come from after the grant period. Name the ownership arrangement and the staff who will hold access. State the intended ending and the review point. Identify what will be done if the funding does not continue, specifically enough that it is a plan rather than an intention.
If the funder will not support ongoing costs, say so internally and decide, with that known, whether the project should still go ahead and at what scale.
Put it in writing before you start
Download the software sustainment plan (.txt). It is a single page covering operating costs, ownership, the intended ending and the review date. Complete it during the proposal and attach it to the project file.
Our Software Care Plan describes what ongoing maintenance involves for an existing system, and the budget guide covers separating one-time costs from recurring ones. If you are scoping a funded project now, talk to us about what it will cost to keep running after the funding ends.