Money spent on software is money not spent on the work. We build what a small team can actually run, starting with donations, volunteers and the reporting your funders expect.
Money reaches a charity by more routes than it reaches most businesses. Online, standing order, cash at an event, a corporate transfer with a reference nobody recognises. We build one donor record that all of those land in, with the payment gateway wired to it so an online gift is receipted within the minute. Recurring gifts, failed cards and refunds are handled in the same place. Your finance volunteer stops reconciling three exports on a Sunday.
Volunteer teams change constantly and peak hard around a campaign or a season. A group chat works until the week it does not. We build a schedule that shows which shifts are covered, and lets a volunteer claim one or hand it back without a coordinator sitting in the middle. Accounts are created by role with an end date on them, so access closes on its own when somebody stops coming rather than waiting for a clear out that never happens.
Funders ask for numbers on their own schedule and in their own format. If the report is built by hand, it will be built again next quarter. We work out which figures each funder wants, then set the systems to record them as the work happens. The report becomes an export. Someone still reads it, and nobody rebuilds it. On cost, we start from what you already own. Most vendors offer charity pricing or donated licensing, and we claim it before quoting you for anything new.
A restricted gift is not a donation with a note on it. It is money that may only be spent on one thing, and somebody will eventually ask you to prove it was. That means the fund is recorded when the money arrives rather than reconstructed at the year end. It also means the system has to hold a gift that splits across two funds, an appeal that raises restricted and unrestricted income in the same week, and expenditure coded back to the pot it came from. Charities that tag funds afterwards find a year of donations cannot be sorted honestly, because the person who knew what a bank reference meant has left. The test we build to is simple: a trustee picks one payment and follows it back to the fund that allowed it.
Almost every vendor runs a non profit programme, and we claim what is available before quoting you for anything, because it is genuinely worth having. It is also worth reading. The donated tier is rarely the product in the marketing pages: seats are capped, administrative controls are thinner, the interface an integration needs is sometimes the one held back for paying customers, and eligibility is reassessed on a timetable that is not yours. A grant covering hosting for a year is not a renewing budget line. So the design assumes the day the terms change. Data that exports without us, no workflow that exists only inside a donated tool, and an honest note of what year two costs. Cheap software you cannot leave becomes expensive later.
Online, standing order, cash at an event and a bank transfer with a reference nobody recognises, all landing in one donor record, with recurring gifts, failed cards and refunds handled in the same place.
Restricted or unrestricted, decided as the money arrives, including gifts that split across two funds. This one field is what makes the year end an export rather than an investigation.
Declarations captured at the moment of giving, receipts issued in the form your tax rules require, and a claim that can be rebuilt from the donation records sitting behind it.
Shifts a volunteer can claim and hand back without a coordinator sitting in the middle, with accounts created by role and an end date on them so access closes without a clear out.
The figures each funder asks for, decided first and recorded as the work happens, so the quarterly report is generated and read rather than assembled over a week nobody has.
Case notes behind their own permissions, kept apart from fundraising, with a retention date on the record itself rather than an intention in a policy document.
Usually the system you already have and rarely the one to replace first. We make it the single donor record and remove the three spreadsheets that grew up around it.
Charity rates are worth asking for. The part that decides your Sundays is the settlement file, which has to reconcile to the donation records without a volunteer matching lines by hand.
Where restricted and unrestricted balances actually live. The donation system feeds it rather than competing with it, and the fund codes have to be the same words on both sides.
Claimed before anything is bought, then read carefully. Capped seats, thinner admin controls and reassessed eligibility are the normal terms of these programmes rather than the exception.
Where the work itself is recorded. Its data answers to different rules from fundraising data, and the join between the two should be counts and outcomes rather than names.
The donation page is the most expensive software a charity owns, measured in what it loses rather than what it costs. Almost everything else can be improved later than this can.
Walk it on a phone, on a weak connection, with a card that fails. Most charities find a step that quietly loses people, and fixing it costs less than any licence in the plan.
Fundraising, finance and the programme team working from the same record removes a weekly reconciliation and makes every report after it possible rather than heroic.
A small change with a long tail. It is the difference between a year end export and three people reading bank references in January trying to remember an appeal.
Build for a single funder first. Their questions are concrete, the work is bounded, and the pattern usually covers most of what the others will want next.
Usually into the donation flow and the donor record, in that order. A donation page that loses people at the payment step costs more than any software licence, and a donor record scattered across spreadsheets costs staff hours every week and makes reporting a reconstruction. Both are contained pieces of work with a return you can see in a quarter.
That is one of the main reasons to build it. Funder reporting is usually rebuilt by hand from exports because the data was never recorded in a shape that matched the questions. Deciding those questions first and recording against them turns a week of assembly into a report that is generated.
As part of the donation flow rather than as an afterthought, since both depend on data captured at the moment of giving. Declarations, receipts and the records behind a claim come off the same donation record, which is also what makes an audit straightforward rather than a search.
That is the design constraint that matters most here, because volunteer turnover is high and nobody has time to train. It means fewer screens, obvious defaults, and forgiving behaviour when something is entered wrongly. Software built for staff who use it daily fails badly when handed to someone using it for the third time this year.
Usually, and we look for that before quoting anything. Most large vendors run a non profit programme, and between them they will often cover email, storage, a share of cloud hosting and the CRM. The edges are the part to plan for. Donated tiers cap seats, thin out the administrative controls, sometimes exclude the very interface an integration needs, and eligibility gets reassessed on somebody else's schedule. A grant that covers hosting for a year is not a budget line that renews itself. So we design for the day the terms change: documented exports, no rule that exists only inside a donated tool, and a written note of what year two costs if the programme ends.
By coding the fund at the moment the money arrives rather than at the end of the quarter. A restricted gift carries a condition, and that condition has to travel with the donation record, with the spending against it, and into the report that eventually cites it. Single gifts sometimes split across two funds, and an appeal raises restricted and unrestricted income in the same week, so the system holds a split instead of forcing a choice. Retrofitting fund codes onto a year of donations is the work nobody budgets for and it is rarely finished accurately. The test is whether a trustee or an auditor can pick one payment and trace it back to the pot it was allowed to come from.
This is the risk we design against first, because it is the one that actually ends charity systems. Nothing is built in a personal account and nothing depends on one person's login, phone or laptop. Domains, hosting and administrative access are registered to the organisation, with a trustee able to recover them. Data can be exported without us. The handover note is written for the next volunteer and for a trustee who is not technical, in plain language, with the few things that must happen monthly listed separately from the things that can wait. If we build something only we can run, we have made your position worse rather than better.
Structurally, rather than by policy alone. Beneficiary records and donor records answer to different rules and belong behind different permissions, so a fundraising volunteer working on an appeal cannot open a case note. Access is granted by role, for a reason, and reviewed. Case notes carry a retention period with an actual date on them rather than a vague intention. Reports to funders are built from counts and outcomes rather than names, which is usually what they wanted anyway. The largest real risk in most small charities is not a breach of the CRM, it is a spreadsheet of service users on a shared drive that everyone can open and nobody remembers making.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
