What the second year costs, and who pays for it
Maintenance is the least fundable line item in the sector and the single best predictor of whether a tool survives.
Almost every nonprofit technology failure we have examined looks the same in retrospect. Year one is a success. There is a pilot, a launch note, a photograph of a field team holding a tablet. Year two is silence.
The mechanics are mundane. The volunteer developer who built it takes a job. An operating system update breaks the sync. A state changes a form and nobody can edit the schema. The one person who understood the deployment moves teams. None of this is dramatic, and none of it is fundable: no donor committee has ever been excited by a line item called maintenance.
Free tools with no maintainer are the most expensive option available.
So the arithmetic quietly inverts. The cheapest software an organisation can adopt is the software somebody is contractually obliged to keep alive. Free tools with no maintainer are the most expensive option available, because their cost arrives as a collapsed programme two years later.
We budget for year two before year one begins. The handover includes the code, the documentation, the model weights and a named person who answers when something breaks. It is unglamorous, it does not photograph well, and it is the difference between a pilot and an institution.
If you are a funder reading this: fund the deployment, not the pilot. Ask what happens in month eighteen. The answer tells you more about the outcome than any theory of change.
What maintenance actually covers
Maintenance is a vague word for a specific list. Operating system and dependency updates. Schema changes when a state alters a form. Model drift when the language or the caseload shifts. Device replacement. Re-training after staff turnover. Security patching. Someone reachable when a sync silently stops.
None of these appear in a theory of change, and all of them decide whether a deployment is alive in month twenty-four. Priced honestly, they run at a meaningful fraction of the original build each year. Priced at zero, they are simply deferred until the system fails.
Key points
- Year-two failure is operational, not technical: turnover, schema drift, unpatched dependencies.
- Maintenance is rarely fundable, which is precisely why it predicts survival.
- Free software without a named maintainer carries the highest total cost.
- Ask what happens in month eighteen before funding anything.
How to write maintenance into a grant
The practical fix is contractual rather than technical. Name a maintainer in the grant. Specify a response window. Budget a recurring line at a defined percentage of build cost, and require a handover package including source, documentation, model weights and an operational runbook.
Funders sometimes resist this on the grounds that it reduces the visible output of a grant. The counter-argument is simple arithmetic: a deployment that survives four years at a modest annual cost delivers more than two pilots that each die at eighteen months.
Questions this raises
What percentage should a maintenance line be?
As a planning figure, fifteen to twenty-five per cent of build cost per year, depending on how much the regulatory or data environment moves.
Who should hold the maintenance contract?
The implementing organisation, not the funder. It needs to be enforceable by the people who feel the failure.
Does open-sourcing solve this?
Only partly. Open source makes a rescue possible; it does not make anyone responsible.