What to Build for UK Non-Profits: Where the Budget Goes First

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: CEO or Operations Director of a UK charity or foundation with 20–150 staff, holding a Charity Commission registration, who controls a technology budget of £50k–£300k and is deciding which systems to commission first after years of patched-together spreadsheets and donor databases the original supplier no longer supports

If you run a UK charity with 20–150 staff and a technology budget between £50k and £300k, the first thing to build is almost never a full donor CRM. It is the HMRC-compliant Gift Aid audit trail underneath it. Then grant reporting automation. Then volunteer coordination. Everything else — the shiny engagement dashboards, the AI-written appeals, the mobile app — can wait, and most of it should.

This is the opposite of what vendors pitch. Their decks start with a unified platform and end with an implementation fee. But the operational bleed in UK non-profits is specific, measurable, and sits in three places. Fix those, and the CRM question answers itself.

The three problems that cost you real money

1. Gift Aid claims assembled months after the donation lands

UK charities claimed £1.7 billion in Gift Aid in the year to April 2025, up 7% on the previous year. They also left an estimated £560 million on the table. The money goes unclaimed for a boring reason: a finance officer is reconciling donations from JustGiving, Stripe, a direct debit file, and a shoebox of event cheques against a donor database that does not know which of those donors have a valid Gift Aid declaration on file.

The non-obvious part is the compliance risk underneath the lost revenue. HMRC can audit Gift Aid claims up to four years after submission and requires an auditable trail: each donation linked to an identifiable donor holding a valid, signed Gift Aid declaration covering the date of that gift. If the trail is broken, HMRC can claw back a pro-rated value of the last four years of claims. Most off-the-shelf donor databases will let you tick a "Gift Aid" box on a donation without enforcing the declaration link, the date range, or the evidence of consent. That is a compliance debt that compounds silently until the audit letter arrives.

2. The same outcome data re-keyed into five funder portals

If you hold grants from the National Lottery Community Fund, a couple of trusts, a local authority, and a corporate foundation, your programme manager is logging the same beneficiary numbers, demographic breakdowns, and outcome metrics into five different web forms on five different schedules. Each funder has its own taxonomy. Each wants a slightly different cut.

This is not a reporting problem. It is a data model problem. The outcomes exist — they are in case notes, attendance sheets, sometimes a Salesforce instance a former ops manager set up in 2019. They are just not stored in a shape that can be sliced on demand. Every quarter, someone spends two weeks doing the slicing by hand.

3. Volunteer coordination held together by one person's inbox

Only 44% of UK charity volunteer programmes have invested in a volunteer management system, despite 92% of organisations calling volunteers critical to delivering their mission. The usual shape: a volunteer coordinator runs everything from email threads, a WhatsApp group, and a Google Sheet. When they are on leave, shifts go uncovered. When they leave the charity, institutional memory walks out with them.

At small scale this is annoying. At the scale of a food bank network or a hospice with 400 volunteers across six sites, it is a service-delivery risk.

What to build first, and in what order

Build 1: The Gift Aid-compliant donation record

This is the foundation, and it is less glamorous than a CRM. You are building a single donation record that enforces, at the database level, the fields HMRC expects:

• Donor identity (name and home address, at minimum) tied to a unique donor ID
• A Gift Aid declaration record with date of signature, declaration wording, channel of capture, and validity range
• Every donation timestamped and linked to both the donor ID and the applicable declaration
• Payment channel reconciliation: JustGiving, Stripe, GoCardless, bank feed, cash — all landing in the same record with the original transaction reference preserved
• A claim-ready export in HMRC's ChR1 or Charities Online schema

What changes once it exists: your finance team submits Gift Aid monthly instead of quarterly or annually. You stop under-claiming because declarations are matched automatically. If HMRC writes, you produce the audit trail in an afternoon rather than hiring a consultant for six weeks. And — this matters — every subsequent system you build (CRM, fundraising app, grants module) plugs into a donor record that is already compliant.

What this is bad at: it will not, on its own, help you steward major donors, run appeals, or segment supporters. That is the CRM layer, and it comes next. Resist the temptation to build both at once; the compliance layer needs to be rock solid before you pile engagement features on top.

Build 2: Grant reporting as a data pipeline, not a document

The second build is an outcomes database that the programme team actually updates in the course of their work — attendance, referrals, case progression, demographic fields — and a reporting layer that produces each funder's required cut on demand.

Three design decisions matter:

• Capture at source. If your support workers are already logging sessions in a case management tool, that tool is where the outcome data should live. Do not build a separate "impact" system that duplicates entry.
• One canonical taxonomy, many funder mappings. You store beneficiary data in your terms. You maintain a mapping file per funder that translates your fields into theirs. When a funder changes their reporting template (they will), you update one mapping, not every record.
• Portal submission is optional. Some funder portals have APIs. Most do not. For the ones that do not, generate the exact CSV or PDF the portal expects and let a human upload it. Automating the last mile rarely justifies the cost.

What changes: quarterly reporting goes from a two-week scramble to a two-day review. Your programme leads get live dashboards of their own outcomes, which they currently see only when reports are being written. And when a new funder asks for a bespoke cut during a bid, you can produce it in hours.

Build 3: Volunteer coordination that survives the coordinator going on leave

The third build is a volunteer management system with four features and no more:

• A volunteer profile with skills, availability, induction status, and DBS expiry
• Shift or opportunity publishing with self-serve sign-up
• Automated reminders and no-show flags
• A simple admin view of who is covering what, visible to more than one person

You can buy this. Rosterfy, Assemble, Better Impact, and others do it well. Build it only if your coordination model is genuinely unusual — multi-site rota logic with clinical qualification matching, for example, or deep integration into an existing case management system. For most charities, the right call here is procure, not build, and spend the engineering budget on builds 1 and 2.

What not to build yet

A few things vendors will push that are usually premature:

• An AI chatbot for donor queries. Your donor queries are mostly "please change my direct debit" and "can I have a Gift Aid receipt?". Fix the underlying data first; the chatbot is a six-week project once the data is clean and a nightmare before.
• A custom mobile app for supporters. Unless you have a genuinely transactional use case (event check-in, peer-to-peer fundraising at scale), a mobile-responsive website does the job.
• A full data warehouse and BI stack. You do not need Snowflake. A well-modelled Postgres database with a reporting layer like Metabase will serve a 150-staff charity for years.
• Blockchain anything. Still no.

How to think about the budget

A working benchmark for UK charity technology spend is 2–4% of total income annually, covering licences, internal or fractional IT, and services. A £5m-income charity spending £40k a year on tech is under-investing and almost certainly accumulating the exact Gift Aid and reporting debt described above. The Charity Digital Skills Report shows 68% of charities cite financial pressure as the main blocker to digital progress — but under-spending on the foundations is what makes everything downstream more expensive.

For a one-off build programme in the £50k–£300k range, the shape of the cost is driven by four things, not by vendor rate cards:

1. How many payment and donation sources you need to reconcile. Two (Stripe + direct debit) is a different build from seven (add JustGiving, Enthuse, GoCardless, PayPal, bank feed).
2. Whether you have a clean donor record to migrate from, or 15 years of spreadsheets with duplicate entries and no declaration dates. Data migration is where most charity projects overrun. Budget for it honestly; the clean-up is often 30–40% of total effort.
3. How many funder reporting formats you need on day one. Three is manageable. Twelve is a programme in itself.
4. Whether build 3 (volunteers) is bought or built. Buying typically runs as a per-seat licence; building is a one-off capital cost plus ongoing maintenance.

An illustrative example — and treat this as illustrative only, not a quote — a mid-sized charity with two payment processors, roughly 40,000 historical donor records needing clean-up, three active grant funders, and a decision to procure (not build) the volunteer system is a materially smaller programme than one migrating from a legacy CiviCRM, reconciling six payment channels, and reporting to a dozen funders with bespoke templates. The gap between those two shapes is a factor of three or four on both cost and timeline. The specifics that turn a range into a real number are: the number and shape of your current data sources, the state of your Gift Aid declaration records, and how many funders need reporting automation in phase one. Those are the three questions to answer before any vendor conversation.

For the compliance side specifically — and this is worth saying plainly — a qualified charity accountant or auditor should review your Gift Aid processes before and after any build. The software enforces the audit trail; it does not replace the professional judgement on whether your historical claims were correctly made.

Sequencing: twelve months, in three phases

If you have £150k to spend and twelve months to spend it, the sequence that minimises risk looks like this:

• Phase 1 (months 1–4): Gift Aid foundation. Donation record, declaration management, reconciliation across your current payment channels, HMRC-ready export. This is the build that pays for itself fastest — in recovered Gift Aid alone, often inside the first year.
• Phase 2 (months 4–8): Outcomes and grant reporting. Programme data capture at source, canonical taxonomy, funder mapping layer, dashboards for programme leads.
• Phase 3 (months 8–12): Volunteer coordination and CRM layer. Procure a volunteer system; add a lightweight CRM layer on top of the donor record for stewardship, segmentation, and appeals.

Note what is not in this plan: a "discovery phase" that lasts six months and produces a slide deck. The problems are known. The sequence is known. The work is to build.

For charities that want help scoping this work against their current data and funder mix, a short conversation to map the four cost drivers above is more useful than any demo. Our digital transformation and services pages lay out how we approach engagements of this shape.

Frequently Asked Questions

Do we need a full CRM before we can claim Gift Aid properly?

No, and in fact a badly-configured CRM is often the cause of the Gift Aid problem rather than the solution. What you need is a donation record that enforces the HMRC audit trail — donor identity, signed declaration, date range, donation linkage. That can sit under any CRM you choose later, or none at all.

Should we build or buy our charity CRM?

Buy the CRM. Build the Gift Aid and outcomes data layer underneath it. The global nonprofit CRM market is worth billions precisely because mature products exist — Salesforce NPSP, Beacon, Donorfy, Blackbaud. What is rarely available off-the-shelf is a compliance-grade data layer tuned to your payment channels and funder reporting needs. That is where custom build earns its keep.

What does a charity Gift Aid and reporting build typically cost?

The honest answer is that the range is wide because the drivers vary. The number is shaped by how many payment sources you reconcile, the state of your historical donor data, how many funder reporting formats you need, and whether volunteer management is bought or built. Any firm number before those are scoped is a guess. The way to get a real figure is a scoping conversation that maps your current systems and data against those four variables.

How long does it take to see Gift Aid recovery improve?

Once the compliant donation record is in production and historical declarations have been matched, most charities see Gift Aid claim volume increase from the first submission cycle after go-live. The bigger recovery — catching up on unclaimed eligible donations within the four-year window — depends on the quality of your historical data and whether declarations can be re-matched or need to be re-captured from donors.

Is an HMRC Gift Aid audit actually likely?

HMRC has a four-year investigation window and runs both random and risk-based audits. The probability for any single charity in any single year is low; the consequence if your audit trail is incomplete is high, because clawback is pro-rated across the full four years of claims. This is a classic low-probability, high-impact risk — the kind that software is well-suited to eliminate at the design stage rather than defend against after the fact. A charity auditor should review your specific processes.