Donor Management Software for Small Nonprofits: Buy, Extend or Build

Most small nonprofits should buy donor management software, not build it. Published plans start at $45 a month for up to 2,500 records (Little Green Light) and £33.50 a month billed annually for up to 2,000 contacts (Beacon). Extend a tool with a small integration when one workflow is missing. Build only when the software is your product.

This guide is for founders, executive directors and volunteer treasurers at small US and UK nonprofits, usually with fewer than 10,000 supporters and one or two people who touch the donor database. RAITHub has not shipped a nonprofit or donor management product. Everything below is engineering guidance, drawn from payment, permission and data-model work on other platforms and labelled that way. RAITHub builds custom software, so it has a reason to say "build". For most readers it shouldn't. Every vendor figure is quoted from the vendor's own pricing page, checked on 30 September 2026; plans change, so confirm before you sign.

What does a small nonprofit actually need from donor management software?

A reliable record of who gave what, when, to which fund, and whether you may contact them again. Everything else is optional in year one. A donor database (also called a nonprofit CRM, customer relationship management system) earns its cost by making four jobs boring: recording gifts, thanking donors, reporting to your board and accountant, and not emailing people who asked you to stop.

Capability	Why it matters	Year one?
Donor records with de-duplication	Two records for one person means two thank-you letters and a wrong lifetime total	Yes
Gift entry by fund and campaign	Restricted money must be reported separately; your accountant will ask	Yes
Online donation form, one-off and recurring	Recurring gifts are the most predictable income a small charity has	Yes
Receipts and acknowledgments	US donors need written acknowledgment for larger gifts; UK charities need Gift Aid records	Yes
Consent and unsubscribe tracking	Marketing rules differ by country and channel	Yes
Reports: income by month, fund, campaign; lapsed donors	Board packs and grant reports	Yes
Export of everything	If you cannot leave, the price will rise	Yes
Volunteer management, events, wealth screening, AI scoring	Useful at scale; noise for a 500-donor charity	Later

If a tool does the "Yes" rows well and lets you export your data, it is good enough. Choose on those rows, not on the length of the feature page.

How much does donor management software cost for a small nonprofit?

Between about $45 and a few hundred dollars a month for most small organisations, priced by the number of donor records you store, not by users. The table below is what each vendor's pricing page said when checked. It is not a ranking, and other tools exist.

Tool	Market	What the pricing page says	Priced by
Little Green Light	US	$45 a month up to 2,500 constituent records, $60 up to 5,000, $75 up to 10,000; 30 days free with no card; 10% off for 12 months prepaid	Records
Bloomerang	US	Bloomerang CRM shown at $125 a month and The Giving Platform at $242 a month, both billed annually, with pricing "based on the amount of records"; "every plan comes with unlimited users"	Records
DonorPerfect	US	Core, Plus and Pro; "starting at $99/month", with plan prices by quote	Quote
Salesforce Nonprofit Cloud	US and global	Eligible nonprofits get 10 Nonprofit Cloud Core licences at no cost through Power of Us; paid editions from $70 per user a month, billed annually	Users
Beacon	UK	Starter £33.50 a month billed annually (£37 monthly) for 500 to 2,000 contacts and 3 users; Standard £114 a month billed annually	Contacts
Donorfy	UK and Europe	Starter, Professional and Enterprise, priced by peak supporter count each month; Gift Aid HMRC integration included	Supporters

Sources: Little Green Light pricing, Bloomerang pricing, DonorPerfect pricing, Salesforce Nonprofit Cloud pricing, Beacon pricing and Donorfy pricing, all checked 30 September 2026.

Three costs sit outside the subscription:

• Payment processing. Card fees go to the processor, not the CRM. Little Green Light, for example, quotes online donation processing "starting at 2.2% + $0.30 per transaction paid to the payment processor (no fee to LGL)". On a $25 monthly gift that is about $0.85 a month.
• Set-up time. Free licences are not a free system. A platform you configure yourself, such as Salesforce, needs someone who knows it; budget for that person or partner before you accept the licences.
• Growth in records. Record-based pricing rises as your list grows, including lapsed donors. Archive or merge before you move up a tier.

Should a small nonprofit buy, extend or build donor software?

Buy by default, extend when one specific workflow is missing, and build only when donor data is part of a product you run or sell. The honest split for small organisations is lopsided.

Your situation	Usually the right move	Why
Under 5,000 donors, a spreadsheet today, one part-time fundraiser	Buy	A $45 to $125 a month tool replaces the spreadsheet; custom software would cost years of subscriptions before its first gift
A tool you like, but one missing piece: a custom donation page, a grant report, a sync to your programme database	Extend	A small integration through the vendor's API keeps the ledger where it is
Donors are also service users, members or beneficiaries, tracked in another system	Extend first, then decide	Two systems with a clean sync often beat one custom system nobody can support
You run a giving platform for many charities, or donations are one feature of your own product	Build	The software is the product, and no donor CRM is built to be embedded in yours
You tried two tools and both fight your model: pledges, matched funds, peer-to-peer teams, several currencies	Build a narrow piece, or buy a platform that is configurable	Build the part that is actually different, not a whole CRM

The same reasoning applies to no-code tools. If you are tempted to assemble a donor database in a no-code builder, the no-code vs custom development guide and the Bubble vs Lovable vs custom comparison set out where each approach stops working. For donor data, a purpose-built nonprofit tool usually beats both.

What does "extend" look like in practice?

A small service that sits beside your donor tool and talks to it through its documented API, doing one job the tool does not. Common examples:

1. A branded donation page that takes payment with Stripe and posts the gift into the CRM, when the tool's own form cannot match your campaign.
2. A grant or board report that joins donor data with programme data from another system.
3. A one-way sync from a membership, ticketing or event system, so gifts do not get typed in twice.

Before you commission any of these, ask the vendor three things in writing: is there an API with write access on your plan, what are its rate limits, and does it expose webhooks (notifications the tool sends when something changes). If the answers are no, the integration will be fragile, and that is a reason to choose a different tool, not to build around it.

If you do build, what does the donation data model look like?

Keep the donor, the gift, the recurring commitment and the acknowledgment as separate records, store money as integers in the smallest unit with a currency on every row, and make it impossible for a replayed payment notification to create a second gift. This is a minimal sketch written for this post, in PostgreSQL:

CREATE TABLE donor (
  id            uuid PRIMARY KEY,
  kind          text NOT NULL CHECK (kind IN ('individual', 'organisation')),
  display_name  text NOT NULL,
  email         text,
  country       char(2) NOT NULL,              -- 'US', 'GB'
  merged_into   uuid REFERENCES donor(id),     -- de-duplication keeps history
  created_at    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE recurring_gift (
  id                      uuid PRIMARY KEY,
  donor_id                uuid NOT NULL REFERENCES donor(id),
  amount_minor            bigint NOT NULL CHECK (amount_minor > 0),  -- cents or pence
  currency                char(3) NOT NULL,                          -- 'USD', 'GBP'
  billing_interval        text NOT NULL CHECK (billing_interval IN ('month', 'year')),
  stripe_subscription_id  text UNIQUE,
  status                  text NOT NULL CHECK (status IN ('active', 'past_due', 'cancelled'))
);

CREATE TABLE donation (
  id                   uuid PRIMARY KEY,
  donor_id             uuid NOT NULL REFERENCES donor(id),
  recurring_gift_id    uuid REFERENCES recurring_gift(id),
  amount_minor         bigint NOT NULL CHECK (amount_minor > 0),
  currency             char(3) NOT NULL,
  received_at          timestamptz NOT NULL,
  fund                 text NOT NULL DEFAULT 'unrestricted',  -- restricted funds are reported separately
  campaign             text,
  benefit_value_minor  bigint NOT NULL DEFAULT 0,            -- goods or services given in return
  source               text NOT NULL,                        -- 'stripe', 'cheque', 'cash', 'import'
  external_ref         text,                                 -- e.g. the Stripe invoice ID
  UNIQUE (source, external_ref)                              -- a replayed webhook cannot add a gift
);

CREATE TABLE acknowledgment (
  id                uuid PRIMARY KEY,
  donation_id       uuid NOT NULL REFERENCES donation(id),
  sent_at           timestamptz NOT NULL,
  template_version  text NOT NULL   -- the exact wording the donor received
);

Four decisions matter more than the SQL:

• Never add USD to GBP. A charity with US and UK supporters reports each currency separately, or converts at a recorded rate on a recorded date.
• Record what the donor got back. benefit_value_minor feeds both US acknowledgments and UK Gift Aid rules, which treat gifts with benefits differently.
• Merge, don't delete. Duplicate donors are merged into one, with the old ID pointing at the survivor, so reports and audit history stay intact. Every change to a gift should be logged; the audit log design guide covers the pattern.
• Permissions from day one. A volunteer entering cheques should not see major-donor notes. The RBAC design guide shows how to write that down as a permission matrix.

How should recurring donations work with Stripe?

Use Stripe Billing subscriptions for monthly or annual gifts, and treat Stripe's webhook events, not the browser redirect, as the moment a gift is recorded. Stripe says subscriptions generate invoices, attempt collection and handle retries and dunning for you; listen for invoice.paid to confirm a payment and invoice.payment_failed to follow up a failed one, and verify webhook signatures before processing events (Stripe: how subscriptions work).

One trap catches donation forms. Stripe's "customer chooses price" option is built for tips and donations, but its documentation says pay-what-you-want payments "don't support recurring payments", only allow one line item with quantity 1, and cannot use promotion codes (Stripe: let customers decide what to pay). For a "give $15 a month" form, create the recurring price from the amount the donor chose, on your server, and start a subscription with it. Stripe also points to its requirements for accepting donations, which you should read before going live.

Stripe event	What the donor system should do	What must hold if it arrives twice
invoice.paid	Record the donation against the recurring gift; queue the thank-you	One donation per invoice, enforced by the unique external_ref
invoice.payment_failed	Mark the gift past due; send a polite "update your card" email	One email per failed attempt, not per delivery
customer.subscription.deleted	Mark the recurring gift cancelled; stop expecting income	Cancelling twice is harmless

The mechanics are the same as SaaS billing, which the Stripe billing guide covers step by step. Test them properly: the payments and webhooks testing guide shows how to replay events and simulate failures before a real donor's card is declined.

What receipts and records do US and UK donors need?

US and UK rules differ, and this is general information, not tax advice; confirm the current rule with your adviser.

• US. The IRS says charitable contributions of $250 or more need written acknowledgment from the organisation, stating the organisation's name, the cash amount (or a description, not the value, of a non-cash gift), whether any goods or services were provided, and a description and good-faith estimate of their value if so (IRS: written acknowledgments). Your system should produce that letter from the donation record, and keep the version of the wording you sent.
• UK. Charities can claim 25p for every £1 an eligible individual donates through Gift Aid, provided the donor has made a Gift Aid declaration and paid enough UK tax (GOV.UK: claim Gift Aid). The declaration, and a record linking each gift to it, is what your database has to keep. Tools such as Beacon and Donorfy build this in; a custom system has to model it carefully.

How should a donor database handle marketing consent?

Store consent per channel, with the date, the source and the wording shown, and honour an unsubscribe everywhere at once. The rules are country-specific. In the UK, the ICO says a new charitable purposes soft opt-in commenced on 5 February 2026: a charity may send electronic mail marketing to people who gave it their details directly while supporting or expressing interest in its charitable purposes, if it offered a simple opt-out at collection and in every message, and only for details obtained on or after that date (ICO: electronic mail marketing rules). That date is exactly the kind of fact your data model must record, because the rule turns on when you collected the address. US email rules are different; check them with your adviser. Either way, a record of when and how each person agreed is the thing to design for.

How do I move my donors from spreadsheets into a new system?

Clean before you import, move balances and history you actually use, and check by hand afterwards.

1. Freeze a cut-over date and stop editing the spreadsheet after it.
2. De-duplicate on email, then on name and postcode or ZIP code. Spreadsheets kept by several people almost always hold duplicates; decide which record wins before the import, not after.
3. Map every gift to a fund. Unrestricted by default, restricted only where you can show the restriction.
4. Carry consent across with its date and source. A consent without a date is a consent you cannot prove.
5. Reconcile totals: income by year and by fund in the new tool should match your accounts.
6. Spot-check 10 donors by hand, including your largest and your oldest.

What does a custom donor system cost compared with a subscription?

RAITHub does not publish rates; every build gets a fixed written quote after a free 15-minute technical audit. The comparison that matters is time: a tool at $125 a month costs $4,500 over three years, and a custom donor system with payments, receipts, consent, roles and reports costs well above that before it records its first gift, then needs hosting, monitoring and upkeep. The monthly running cost guide covers the upkeep side, and the MVP cost estimator gives a first range for your feature list. If the number does not clearly pay for itself through something no subscription can do, buy the subscription.

How does working with a Dhaka team fit US and UK nonprofit hours?

RAITHub works from Dhaka, UTC+6, with no daylight saving. US clients get a daily 2-hour evening overlap, Dhaka 19:00 to 21:00, which is 08:00 to 10:00 in New York. UK teams get about 3 hours of overlap in winter and 4 in summer. The working week is agreed per client, and everything outside the overlap runs on written daily handoffs, which suits a part-time trustee or treasurer who reads updates in the evening.

Why RAITHub for this

• Recurring payments are built and tested. PropDesk, a property management platform RAITHub built, collects rent with Stripe and has 1,024 automated tests. Recurring gifts, failed-payment follow-up and idempotent webhook handling are the same engineering problem. RAITHub has not built a donor system; that would be new work, quoted as such.
• Permissions that match real roles. Sundor Skin, a B2B wholesale platform, has 88 permission codes and 12 staff roles, the kind of detail that keeps a cheque-entry volunteer out of major-donor notes.
• Integrations, not just rebuilds. Most nonprofits need the "extend" option: a donation page or sync that talks to the tool they already pay for. See API and backend development for what that work involves.
• Clear terms. A free 15-minute technical audit, then a fixed written quote, fixed scope or a dedicated monthly team. You own the IP, and an NDA is standard. RAITHub is not SOC 2 or ISO 27001 certified; it signs DPAs and SCCs and follows your controls.

When you don't need us

• You have fewer than a few thousand donors and a spreadsheet. Buy a nonprofit tool. Start a free trial this week; that is a better use of your budget than any custom build.
• Your tool does the job but nobody has set it up properly. You need a consultant for that product, or a free afternoon with its help docs, not software development.
• You want tax, Gift Aid or charity-law advice. Talk to an accountant or adviser; RAITHub builds the rules they give you into software.
• You need a native iOS or Android app. RAITHub builds web apps and PWAs only.
• You want a developer placed in your team by the hour. RAITHub does not offer staff augmentation.

If you already have a custom donation form or donor database that loses gifts or double-charges, start with a fix rather than a rebuild.

Sources checked on 30 September 2026. Tax, receipting and marketing rules are general information only; confirm the current rule with your adviser.

If your donor tool is missing one workflow, or you are building donations into your own product, book the free 15-minute technical audit. Bring your current tool, your donor count and the one thing it cannot do.

Frequently asked questions

What is donor management software?

Donor management software is a database built for nonprofits that records donors, gifts, funds, campaigns, acknowledgments and communication preferences. It replaces spreadsheets so that thank-yous, board reports and fundraising appeals come from one accurate record of who gave what.

How much does donor management software cost for a small nonprofit?

Published entry prices checked in September 2026 include Little Green Light at $45 a month for up to 2,500 records and Beacon at £33.50 a month billed annually for up to 2,000 contacts. Most tools price by the number of records, so the cost rises as your list grows.

Should a small nonprofit build its own donor database?

Usually not. A subscription at $45 to $125 a month costs far less over three years than building and maintaining custom software. Build only when donations are part of a product you run, or when two tools have failed to model how you work.

Can I use Stripe for recurring donations?

Yes. Use Stripe Billing subscriptions for monthly or annual gifts and record each gift when the invoice.paid webhook arrives. Stripe's pay-what-you-want option does not support recurring payments, so create the recurring price from the donor's chosen amount on your server.

Is Salesforce free for nonprofits?

Salesforce says eligible nonprofits receive 10 Nonprofit Cloud Core licences at no cost through its Power of Us programme, with paid editions from $70 per user a month billed annually. The licences are free, but configuring and maintaining Salesforce usually needs a skilled administrator or partner.

Has RAITHub built donor management software?

No. RAITHub has not shipped a nonprofit product. It has built Stripe recurring payments in PropDesk, with 1,024 tests, and detailed role permissions in Sundor Skin. For donor systems, RAITHub offers engineering guidance, integrations and custom builds quoted as new work.