Software for UK small-to-medium charities
Eight thousand pounds of historic Gift Aid recovered when we got the declarations + the batch right. We were leaving that on the table every year.
You’re the CEO at a £450k-income local charity, or the development director at a £4m mid-sized service-delivery charity, or the operations lead at a place-based community-led organisation, or the principal trustee at a small grant-making trust. The fundraising-side stack is the universal mix - JustGiving and Enthuse on the donation side, Donorfy or ThankQ or Salesforce-NPSP or Raiser’s Edge on the supporter CRM, GoCardless and Stripe on the regular-giving plumbing, dotdigital or Mailchimp on the email side. The bookkeeping happens in Xero with the SORP chart and a charity-aware bookkeeper who comes in two days a fortnight. The Gift Aid claim runs monthly through HMRC Charities Online - when it runs; the historic 6% of donations where the declaration’s missing or the donor record’s wrong gets left on the table because nobody quite owns the recovery. The trustee board meets monthly; the pack assembles itself over two days because nobody’s automated the trustee-visible figures yet. The grant deadline pipeline is a Google Sheet that’s accurate when the development director updates it on Sunday night. Charity Commission annual returns and Fundraising Regulator Code adherence are the regulatory wallpaper - the deadlines come round, the assembly is always more work than it should be.
We make custom software for UK small-to-medium charities - scoped per organisation, sized to the bit between the donation landing on JustGiving and the donor thanked in your CEO’s voice, the Gift Aid claimed, the regular giver’s failed DD recovered before she lapses, the trustee pack assembled, the grant deadline not missed, the bookkeeper’s restricted-fund analysis automating itself. Not a Donorfy / ThankQ / Salesforce-NPSP / Raiser’s Edge replacement - the CRMs work for what they’re for. Not a HMRC Charities Online replacement - you’re submitting through HMRC’s portal either way. The bit between the CRM and the operational reality of running the charity - the welcome cascade that lands in your voice not JustGiving’s, the regular-giver lifecycle that catches the DD failure before three months of silence become a lapse, the data hygiene that turns the eighteen-thousand-record Donorfy into something the team trusts again, the Gift Aid recovery the bookkeeper can’t get to, the grant pipeline and trustee pack assembling themselves - that’s the bit we build. Tell us what your week looks like and we’ll come back with a sketch.
What you spend your week on that you shouldn’t have to
- New donation lands on JustGiving Tuesday - £250 with Gift Aid declared. The generic JustGiving thank-you fires, the supporter record imports to Donorfy with the address half-completed, Gift Aid waits for the next batch; the warm thank-you in your CEO’s voice the supporter would have remembered never happens.
- Direct Debit failure rate 4-6% per month - each regular-giver lapse without a personal recovery message is £150-£300 of lifetime value gone, GoCardless auto-retries but the “sorry to see your DD bounced, here’s what your giving means” message lives in nobody’s inbox.
- Donorfy / ThankQ / Salesforce-NPSP supporter database - eighteen thousand records, three thousand active, two thousand five hundred duplicates because JustGiving / Enthuse / Stripe / GoCardless / manual cheques each import with slightly different formats and nobody’s had time to dedupe in three years.
- Gift Aid claim runs monthly - HMRC Charities Online, batch submission, 6% of donations queue as “declaration missing or unclear”. That 6% compounds to £8k-£15k a year you’re leaving on the table.
- Grant deadline pipeline - twenty-plus trusts and foundations you’re tracking, monthly deadlines, the “did we apply for the Garfield Weston before the December cut-off” question lives in a Google Sheet you trust on Sundays and don’t on Wednesdays.
- Volunteer DBS expiry - fifty volunteers, half of them on enhanced DBS for safeguarding-adjacent roles, the spreadsheet of expiry dates is two months behind because the volunteer coordinator’s on maternity leave.
- Trustee board pack - bank reconciliation, restricted-fund movement analysis, KPI dashboard, risk register update, safeguarding report. Currently a Friday-and-Saturday assemble-from-five-tools job.
- Charity Commission annual return due in five months - trustee details + accounts + safeguarding update + serious-incident questions, currently in three different folders.
- Service-delivery case management - six hundred active cases, Plinth or Lamplight as the case CRM, LA quarterly outcomes reports across Suffolk + Cambridgeshire + Essex with each LA’s preferred format different.
- Fundraising Regulator + ICO + Fundraising Preference Service check - old marketing list, half the consent records were re-collected post-2018, the rest are uncomfortable to look at, the FPS check on every new prospect is the volunteer coordinator’s least-favourite Tuesday job.
These aren’t problems a generic CRM solves. They’re the bit between the supporter giving and the supporter retained, the Gift Aid recovered, the grant won, the trustee comfortable, the bookkeeper closing the month on time, the CEO not assembling the board pack on a Saturday. That’s the bit we build.

Example problems we could solve
Five things we hear most often from small-to-medium charities - with what the solved version looks like in your week. Every build is scoped per organisation: a £450k-income local charity probably needs the first three; a £4m service-delivery charity with a grant pipeline and a trustee board might want all five. None of it means binning the CRM you’re running on.
1. The first donation that ends with a thank-you in the CEO’s voice, not JustGiving’s
The generic-thank-you moment: new supporter donates £250 with Gift Aid Tuesday on JustGiving. Generic JustGiving thank-you fires. By Friday the donation’s imported into Donorfy. The warm thank-you in your CEO’s voice - the thing that would have started the relationship, the thing that would have made her a £15 regular giver next month - never happens. The first-donation moment is the single highest-leverage retention point in the supporter relationship, and it’s currently mostly automated to a generic platform thank-you that doesn’t build the relationship.
Solved looks like: every new donation - JustGiving, Enthuse, Stripe-on-website, GoCardless-DD, manual-cheque-entered, in-memory tribute giving - fires an inbound event we capture. The thank-you cascade runs within the hour: a CEO-voice email pre-drafted with the supporter’s name, the cause she chose (literacy / refuge / dementia / food bank / local heritage - whichever programme line her gift went to), the impact framing your charity uses, and a soft “if you’d like to hear how your gift’s helping, here’s the monthly update sign-up” - with the CEO confirming the personal tone before send for first-time donors above the threshold she’s set. For larger gifts (the threshold you set - £100, £500, £1,000), the cascade escalates to a personal phone-call task on the CEO or development director’s list. For supporters giving for the first time, the welcome flow follows - month-1 “here’s what happened with your gift”, month-3 “another way to be involved if you’d like”, month-6 “would you consider becoming a regular giver” - each step in your voice on the channel the supporter responds to (email by default, WhatsApp where she’s opted in for an event or fundraising challenge). The charity-specific moment: the build is shaped around making the first impression land in your voice and on time, not Friday afternoon when the development director catches up with the import.
2. Regular-giver lifecycle - and the DD failure that doesn’t quietly become a lapse
The bounced-DD moment: 4-6% DD failure rate per month. GoCardless / Stripe auto-retries and sends a transactional email. The supporter’s still around - she’s not consciously cancelled - but the warm message that would save the relationship doesn’t land and three months later she’s gone for good. £150-£300 of lifetime value walks out the door each time. Across a base of two thousand regular givers that’s £30k-£60k of revenue a year quietly leaking - the single biggest revenue lever in the trade - and the DD-failure recovery is the conversation nobody owns.
Solved looks like: every regular giver carries a structured lifecycle state - new (first three months), established (3-24 months), loyal (24+ months), at-risk (recent failure or engagement drop), lapsed (declined or 90+ days no recovery) - with a per-state cadence in your CEO’s voice that lands at the right moments. When a DD fails (GoCardless / Stripe flag a failed payment), the at-risk flow runs immediately: a same-day “sorry your DD didn’t go through - your giving means [specific impact framing] and we’d hate to lose it” message in your CEO’s voice, on the channel the supporter responds to (email by default, WhatsApp where she’s opted in); a one-tap payment-method update link that lands her on a PCI-compliant card-update surface; an escalation at +7 days if she hasn’t reinstated, with the framing matched to her tenure (a five-year loyal giver’s recovery message is different from a six-month established one); at +30 days a personal phone-call task lands on the development director’s list for the loyal-tier givers. The longer version lives at Recurring Service Recall; the charity version is anchored on the LTV-by-acquisition-source dashboard (so you can see which donor-recruitment campaigns produced supporters who stay, not just supporters who gave once), the tenure-matched recovery tone, and the upgrade-from-£10-to-£15 conversation as a structured nudge at year-2 and year-5 rather than an awkward annual ask. The charity-specific moment: regular giving is the cashflow spine of UK charity fundraising, the DD-failure-recovery is the single biggest unrealised revenue lever, and the build is shaped around treating the DD as a touchpoint in a relationship rather than a transaction in a payment processor.
3. Donor data hygiene - the eighteen-thousand-record CRM that becomes useful again
The duplicate-Sarah moment: Donorfy / ThankQ / Salesforce-NPSP at eighteen thousand records. Three thousand active, two thousand five hundred duplicates because JustGiving / Enthuse / Stripe / GoCardless each import with slightly different formats. Gift Aid claims fail because the same donor’s address differs across three records of her. The CRM is the firm’s core asset and right now it’s the asset nobody trusts.
Solved looks like: the data-hygiene loop runs as a background process across the supporter CRM. Duplicate detection identifies likely-same-supporter clusters (same email-and-postcode, same email-and-name-and-postcode-prefix, fuzzy-match on name + address + giving-pattern) and surfaces the merge candidates to the development team for one-tap approve; the merge preserves every donation record + every Gift Aid declaration + every consent record + every event registration in one consolidated supporter. Source-specific import normalisation - JustGiving’s address format, Enthuse’s title-handling, Stripe’s metadata mapping, GoCardless’s name fields, the manual-cheque-entered records - all get standardised against your CRM’s canonical shape before they ever enter, so the swamp doesn’t fill back up from next week’s imports. PECR consent state per channel (email, post, phone, SMS) is held as a structured object; marketing messages route only to supporters with explicit consent on the relevant channel; the Fundraising Preference Service cross-check runs against every new contact at the moment of inclusion in a new campaign. Volunteers who’d previously sent without checking get an audit-clear “this supporter is on FPS, would not send” flag before any campaign goes out. The charity-specific moment: data quality is the foundation of Gift Aid recovery, regular-giver retention, and Fundraising Regulator + ICO-safe fundraising - and the multi-platform import reality is what creates the mess, not the supporters themselves. The build is shaped around making the mess invisible by the time it lands in the CRM, not via manual evening clean-up sessions the volunteer coordinator can never get to.
4. Gift Aid recovery - the £8-15k a year the bookkeeper can’t get to
The historic-sweep moment: Gift Aid claim runs monthly through HMRC Charities Online; 6% of donations queue as declaration missing or unclear; you eventually claim 2 of those 6; £8-15k a year sits as un-recovered Gift Aid. Across UK charities nationally HMRC publishes the un-claimed figure at around £600m. The back-four-years historic sweep at onboarding plus the monthly declaration-chase in the CEO’s voice is what recovers it - and right now the bookkeeper can’t get to the chase because she’s reconciling Friday’s bank feed.
Solved looks like: every donation queues against a structured eligibility-check the moment it lands - claim-ready (Gift Aid declared, donor record clean, address current), eligible-but-missing-declaration (the donor’s a UK taxpayer who hasn’t actually ticked the box - historic sweep candidate), eligible-but-missing-evidence (declaration ticked but the donor record’s address is the old one that doesn’t match her tax return), ineligible (clearly not Gift Aid eligible - corporate, anonymous, opt-out). The claim-ready set queues into the monthly batch and submits through HMRC Charities Online via the structured XML format; the response (claim accepted / queried / rejected per donation) writes back to the supporter records. The eligible-but-missing-declaration set enters a declaration-chase cadence in your CEO’s voice - “we noticed you’ve been giving for [tenure] and we don’t have a Gift Aid declaration on file - if you’re a UK taxpayer, ticking this one box adds 25p to every £1 you give us” - with a one-tap declaration link the supporter can sign on her phone in seconds. The historic four-year sweep runs at onboarding (where the rules allow) so the claim covers donations the previous bookkeeper missed; subsequent months are clean from the start. The charity-specific moment: Gift Aid is the most-mentioned-least-recovered revenue in the trade and the recovery is a clean operational problem - the build is shaped around making the recovery the system’s job, not the bookkeeper’s optional Friday-afternoon archaeology project.
5. The grant pipeline + the trustee pack that assembles itself
The Saturday-pack moment: twenty trusts and foundations you track for grant applications - National Lottery + Garfield Weston + Lloyds Bank Foundation + Henry Smith + Esmée Fairbairn + local community foundations. Monthly deadlines. Reporting on previous grants is thirty per cent of fundraising time. The trustee board pack on the first Tuesday of the month is two days of bank reconciliation + KPI assembly + risk update + restricted-fund analysis. Grant pipeline visibility and trustee oversight are the two most time-consuming non-fundraising activities for a £500k-£10m charity.
Solved looks like: the grant pipeline lives as a structured object - each funder with their typical grant size, fit-with-our-cause score, application cadence, named-contact relationship state, prior outcomes you’ve reported. The deadline calendar projects the next six months forward; the “draft application due” prompt fires at lead-time appropriate to the funder (8 weeks for a large trust, 2 weeks for a small one); the application-status pipeline tracks drafted, internal-reviewed, submitted, acknowledged, in-decision, awarded, declined, reporting-due. For previously-awarded grants, the reporting calendar reminds at quarterly + final-report points, with the report-narrative draft pre-filled from the project’s actual delivery (cases supported, outputs delivered, outcomes captured against the grant terms). On the trustee side, the monthly board pack assembles itself - bank reconciliation auto-extracted from Xero (or QuickBooks or Sage 50 / Sage Charity Solution) with the restricted vs unrestricted vs designated funds split, KPI dashboard live against the year’s plan, the safeguarding-and-serious-incident log surfaced for the trustee-attention items, the risk-register changes since last meeting flagged. The CEO confirms the narrative; the pack PDFs against the charity’s template; the trustees receive it 72 hours before the meeting rather than 12. The Charity Commission annual return (AR15 / AR23 / AR40 as applicable to your size band) and the Fundraising Regulator self-assessment narrative pre-fill from the operational data so the regulator submissions are an hour of approval, not a fortnight of assembly. The charity-specific moment: the build is shaped around making the trustee pack and the grant pipeline assemble themselves from data that already exists rather than being weekly archaeology projects.

The closest things we’ve already built
- mendbuddyour own multi-channel AI agent platform for inbound conversations across voice, SMS, WhatsApp, web chat, Facebook Messenger and inbound + outbound voice. The supporter-welcome cadence in problem 1, the DD-failure recovery in problem 2, and the Gift Aid declaration chase in problem 4 are charity-shaped versions of this - trained on your charity’s voice, your cause framing, your CEO’s communication style, and your supporter base’s channel preferences. See Mendbuddy.
- pharmaceutical-analytics.coma custom analytics dashboard we built for an analytics consultancy. The fundraising / regular-giver / Gift Aid / grant-pipeline / trustee-KPI dashboard is the same shape: operational data captured at every supporter and donation touchpoint, decision dashboard for the CEO or development director or the principal trustee. The restricted-fund SORP-compliant view sits naturally on the same data model. See Pharmaceutical Analytics.
- planpostour own social-media scheduling SaaS. The mission-aligned content cadence (impact stories, beneficiary case studies, fundraising-campaign drumbeats, awareness-day commentary, trustee-spotlight series) runs through planpost; the supporter-engagement loop on the social side stays consistent with the cause voice on the email side, and PECR-clean by default - service messages soft-opt-in, marketing content explicit consent - so the campaign that’s been in the drawer two weekends running goes out properly, not at the wrong consent base. See Planpost.
- mendmyiour founder’s service-business storefront with structured intake + payment + status-comms. For small charities running a shop / fundraising-product / events-ticket arm alongside their main work, the shape is the same: storefront + payment + customer-record + receipt flow that integrates into the supporter CRM rather than living as an island. See Mendmyi.
Adjacent verticals
- Domiciliary carefor the charity providing CQC-regulated home care alongside its main mission (some larger health-and-social-care charities); the rota + safeguarding + LA-invoicing patterns transfer directly.
- Clinicsfor clinician-led community-interest companies and small healthcare not-for-profits that overlap the clinic operational pattern.
- Professional servicesfor charity-side consultancy and the small charitable foundations whose work is mostly grant-making (the project + retainer mix appears on both sides of the table).
- Recruiters + HRfor the volunteer-management overlap (DBS + safeguarding-equivalent + onboarding pack shape, particularly for safeguarding-adjacent volunteer roles).
- Accountantsfor the charity-specialist accountant whose practice runs SORP-aligned year-end + Gift Aid claims on your behalf.
FAQ
Will the supporter-welcome cascade work with Donorfy / ThankQ / Salesforce-NPSP / Raiser’s Edge?
Yes for all the named ones. Donorfy exposes a modern API for supporter + donation events; ThankQ likewise on its current cloud version; Salesforce-NPSP via the standard Salesforce API; Raiser’s Edge NXT via its read/write API (the older on-prem Raiser’s Edge 7 we handle via structured export). The welcome cascade reads the new-donation event, fires the cadence in your CEO’s voice, and writes the engagement state back to the CRM as the supporter’s source of truth.
Will the Gift Aid recovery integrate with HMRC Charities Online?
Yes. HMRC publishes the structured XML format for batch submission; the recovery engine queues claim-ready donations into the monthly batch, the submission fires when you approve it, the response (claim accepted / queried / rejected per donation) writes back to the supporter records. The declaration chase for missing declarations runs alongside - declarations re-collected feed the next batch. The four-year historic sweep at onboarding runs once and recovers the back-claims the previous bookkeeper missed.
Will the regular-giver lifecycle handle GoCardless DD failures + Stripe-DD + payment-method changes correctly?
Yes. GoCardless flags a failed DD and the at-risk flow fires immediately; the recovery cadence fires in your CEO’s voice with the tenure-matched framing; payment-method updates capture via a one-tap link that lands the supporter back on her own card-update page (PCI-compliant via Stripe / GoCardless’s own surface, not ours). For Stripe-DD regular givers the same flow applies via Stripe webhooks. Apple Pay / Google Pay updates flow the same way for the supporters who’ve moved their card on the device.
Will the data-hygiene engine respect PECR consent + Fundraising Preference Service + ICO direct-marketing rules?
Yes. Every supporter’s PECR consent state per channel (email, post, phone, SMS) is held as a structured object; marketing messages route only to supporters with explicit consent on the relevant channel; the FPS check runs against every new contact at the moment of inclusion in a new campaign. The audit log shows which basis fired for which message so the Fundraising Regulator self-assessment narrative pre-fills from the actual operational record rather than a retrospective reconstruction.
Will the trustee board pack handle SORP-compliant restricted fund analysis?
Yes. The bank reconciliation extract from Xero (or QuickBooks or Sage 50 / Sage Charity Solution) carries the fund-restriction tagging from your chart of accounts; the restricted-vs-unrestricted-vs-designated split assembles automatically for each trustee meeting, with the movement-between-funds analysis surfaced. SORP 2026 chart-of-accounts updates get reflected in the build when commencement applies. The audit-evidence trail for the year-end accounts assembles in the background so the independent examiner or auditor has one URL when they arrive.
Will you handle the Charity Commission annual return / Fundraising Regulator code-of-practice / safeguarding compliance on our behalf?
No. Trustee accountability under the Charities Act 2011, Fundraising Regulator Code adherence, the safeguarding-and-serious-incident reporting duty all stay with the trustees and the named accountable individuals. What the system does is make the evidence assemble itself - the safeguarding log structured by incident type, the Serious Incident Report draft prefilled from the captured facts, the AR15 / AR23 / AR40 sections pre-filled from the operational data - so when the deadline approaches, the assembly is one screen rather than a Saturday.
Will the system handle the case-management side for service-delivery charities - Plinth / Lamplight / Charitylog?
The case-management CRM stays your system of record on cases and outcomes (it’s the system your LA commissioners look at). What we add is the layer between the case CRM and the fundraising CRM - the impact stories that feed the supporter-welcome cascade in problem 1, the outcomes data that pre-fills the grant-reporting narrative in problem 5, the safeguarding-incident log that surfaces to the trustee pack. The case CRM and the fundraising CRM both stay first-class; we just stop them being two islands.
What does it cost?
Every build is scoped per charity - depends on income band, supporter count, regular-giver volume, grant-pipeline depth, whether the build covers fundraising-side only or includes the service-delivery + trustee-board layers too. We talk it through, agree the scope and the price in writing, then build. Send an enquiry and we’ll come back with a sketch. See pricing for how we work.
How long until something’s live?
The supporter-welcome cascade and the DD-failure-recovery flow typically go from scope conversation to a working version inside a few weeks, with a couple more weeks of running real donations and real DD failures through them before go-live. The data-hygiene engine and the Gift Aid recovery loop ship together inside a couple of months - the historic four-year sweep runs once early. The grant pipeline and the trustee pack assembly slot in alongside as the operational data starts landing into them.

Tell us what your week looks like
What charity you run, income band, fundraising mix (regular giving / one-off / trusts / events / corporate / legacies), CRM stack (Donorfy / ThankQ / Salesforce-NPSP / Raiser’s Edge / Plinth / Lamplight / Charitylog), where the operational pain lives - the un-recovered Gift Aid, the DD that lapsed without a recovery message, the eighteen-thousand-record CRM nobody trusts, the grant deadline pipeline on a Google Sheet, the trustee pack that ate Saturday. Send an enquiry - what you do, what’s slowing you down, what you’ve already tried. We’ll come back with a sketch of what we’d build and what it would cost. No calendar, no demo to sit through. Email reply, scoped sketch, you decide.