The Real Cost of an Outdated Charity Website

Most charity websites have technical debt. The tricky thing is that it rarely announces itself. It builds up gradually - deferred updates, slower load times, a CMS that takes longer to work with than it should. Sometimes a website simply outgrows what it was built to do. Small things, until they aren’t, and suddenly it's all you're dealing with. 

Technical debt accumulates for all kinds of reasons – rushed decisions, changing requirements, underinvestment, or simply time passing. Most charity websites carry more of it than their teams realise, and it compounds quietly in the background, getting more expensive to address the longer it's left. 

What technical debt actually looks like 

Technical debt is the accumulated cost of decisions that made sense at the time but weren't built to last. 

The term comes from software development - Ward Cunningham, one of the authors of the Agile Manifesto, coined it in 1992. His point was simple: when you take a shortcut to deliver something faster, you're effectively borrowing against the future. You'll need to repay it eventually, and the longer you wait, the more interest you owe. 

In practice, on a charity website, technical debt shows up as things like: 

• Slow page load times - especially on mobile, where most of your visitors now are 
• Outdated software versions that require manual workarounds to update safely 
• Donation forms or signup flows that work on desktop but not reliably on other devices 
• Customisations that only one developer understands - or that nobody fully understands anymore 
• Content changes that take far longer than they should because the CMS is fighting against you 

Some of these are more urgent than others – a broken donation form has an immediate financial cost in a way that a slow-loading blog post does not. But even the smaller issues add up, and they compound. 

When we started working with Maggie's, their website carried years of accumulated debt - layers of customisations and technical decisions that had made sense at the time but had become a constraint on everything they wanted to do. The rebuild we undertook wasn't just cosmetic. It was structural, and that structural work is what made everything that followed possible. 

The compounding cost: why it gets more expensive the longer you wait 

A website with technical debt requires more developer time to maintain than one that has been looked after consistently. Left unaddressed, that burden tends to grow, making new work slower, more expensive, and in some cases harder to prioritise alongside everything else. 

The costs aren't all obvious. Some are direct: updates that take longer than they should, more time firefighting, higher development costs when problems become urgent. Some are indirect: 

• Slow websites lose visitors before they've read a word. Google’s own research consistently shows that even a two-second increase in load time significantly raises the likelihood of a visitor leaving, and for a donation page, that has a direct financial cost. 
• Poor performance on mobile affects not just user experience but search rankings. Google uses mobile performance as a ranking signal, so a slow or broken mobile website is also an SEO problem. 
• Security vulnerabilities increase as software versions fall out of date. Outdated software is one of the most common causes of website security incidents. 
• New features become harder and more expensive to build. Developers working on a debt-heavy codebase spend more time understanding existing code and managing side-effects than they do building the thing you've asked for. 

The compounding effect is probably the hardest to communicate to non-technical stakeholders, but it's the most important.  

How to audit your own website: checks anyone can run 

You don't need access to the codebase to get a useful picture of your website's technical health. The following checks are all non-technical, free, and can be done in an afternoon. They won't give you a full technical audit, but they'll give you enough to start a conversation. 

1. Check your page speed 

Run your homepage and your most important pages (donation page, key landing pages) through Google PageSpeed Insights. It gives you a score out of 100 for both mobile and desktop, and flags the specific issues dragging your score down. Anything below 50 on mobile warrants attention. Anything below 30 is urgent. 

2. Look at your Core Web Vitals 

If you have access to Google Search Console, navigate to the Core Web Vitals report. This shows you how Google assesses your website's real-world performance - load time, visual stability, and responsiveness. Pages flagged as 'Poor' here are a problem both for users and for search rankings. 

3. Check when your website’s software was last updated 

Ask whoever manages your website when the codebase and any third-party dependencies were last reviewed and updated. If the answer is vague, or if you know that updates have been deferred because they might break something else, that's worth understanding in more detail. 

 4. Run a broken link check 

Use a free tool like Broken Link Checker to scan your website for dead links. A high number of broken links suggests a website that has grown organically without structural oversight - content removed, pages moved, external links not maintained. It's a useful indicator of general website health. 

5. Look at your analytics for performance signals 

In Google Analytics, look at pages with unusually high bounce rates or very short average engagement times - particularly on pages that should be driving conversions. These can be symptomatic of slow load times, broken functionality, or a poor mobile experience (though poor content or unclear calls to action can equally be the cause). Your donation page and key landing pages are the most important ones to examine. 

Once you have this data, share it with whoever manages your website technically. The numbers from PageSpeed and Search Console are harder to argue with than general impressions. 

Making the case: translating technical problems into organisational impact 

The hardest part of addressing technical debt isn't identifying it. It's getting buy-in from the people who control the budget. 

Leadership teams - particularly in charities, where every spend is scrutinised against mission impact - are understandably reluctant to invest in something they can't see. Frame it as risk, not as a technical problem 

Outdated software can carry security vulnerabilities or compatibility issues. Left unaddressed, these can cause significant downtime, damage donor trust, and take considerable time and money to resolve - a governance issue as much as a technical one. 

Frame it as income risk 

If your donation page is slow, broken on certain devices, or creates friction in the giving journey, you are losing donors at the point of conversion. The M+R Benchmarks report puts average donation page conversion rates at around 12% on desktop and 11% on mobile. That gap has a monetary value that can be calculated, even approximately. 

Frame it as cost efficiency 

Technical debt has a direct effect on how much your digital work costs. Every hour a developer spends understanding legacy code, working around broken integrations, or firefighting avoidable issues is an hour not spent building something useful. If you track development time or agency costs, you can look for patterns: tickets that take much longer than expected, recurring fixes to the same systems, changes that require disproportionate testing. These are the fingerprints of technical debt, and they add up. 

Frame it as a cost curve, not a one-off 

One of the most useful things you can say in this conversation is that the cost of addressing technical debt is lower today than it will be next year. Building that into a budget conversation shifts the question from "why are we spending this?" to "when are we spending this?" 

Where to start 

Most charity websites we work with have some level of technical debt. That's not a criticism, it's a reality of how websites get built and maintained under resource constraints. The question isn't whether it exists; it's whether you have a clear enough picture of it to make informed decisions. 

Start with the checks above. They're free, they take a few hours, and they'll give you something concrete to work with. If what you find raises questions you don't have good answers to - about what's causing your PageSpeed score, what your plugin update backlog actually means, or what it would take to properly address what you've found - that's a reasonable point at which to bring in a technical perspective. 

We do this kind of review regularly as part of how we start working with organisations as a way of understanding what a website actually needs before committing to a direction. If it would be useful to talk through what you're seeing on your website, we're happy to have that conversation.