Non-profit platforms, built for money that arrives with conditions attached.
A restricted donation is not revenue, it is a promise with an audit trail. No ready-made product fits this sector honestly, so everything here is a custom programme built on the engineering practices below.
Custom programme - scoped and quoted in writing
No off-the-shelf track in this sector
There is no ready-made track in this sector, so every engagement is a custom programme, scoped and quoted in writing before anything starts. Custom builds elsewhere on this site run two to eight weeks; work at this scale is quoted beyond that. Every figure on this page is defined on our facts page.
What a non-profit build actually contains
The sequence below is where non-profit platforms are won or lost. Every phase names what it requires and why a commercial equivalent does not transfer.
The reason generic donation and CRM software disappoints this sector is that it models money as revenue. In a charity, money arrives with conditions: this gift funds this programme in this region for this period, and the funder is entitled to be shown that it did. A system that cannot represent that condition forces someone to hold it in a spreadsheet, and the spreadsheet becomes the real accounting system while the software becomes a payment page.
Three of the seven phases have no shortcut, and we mark them as such below. The rest can be compressed, but the fund model, the data protection position and the reporting obligation take the time they take because they are constraints rather than features.
The fund model, before any donation form
Restricted, unrestricted and designated funds behave differently and have to be modelled as different things. A restricted gift can only be spent on what the donor specified; an unrestricted one keeps the lights on; a designated one was set aside by trustees rather than by a donor and can be undesignated by them. Systems that hold one balance and a category label cannot enforce any of this.
Expenditure has to draw from the correct fund, which means the spending side of the platform has to know about the giving side. This is the equivalent of double-entry in a commercial ledger and it is the decision the rest of the build depends on.
Multi-year pledges, matched giving and gifts in kind all complicate the model, and each is far cheaper to design in now than to reconcile later.
Giving, recurring gifts and receipting
Recurring giving is the number that decides whether an organization can plan, and it is also where most donation platforms quietly leak. A failed card renewal that produces no recovery attempt is a supporter lost silently, and card expiry is the single largest cause of lapsed regular giving in most portfolios.
Receipting is a legal instrument rather than a confirmation email. Depending on jurisdiction it carries tax relief claims, declarations the donor must make, and a reporting obligation to a revenue authority. The rules differ by country and the platform has to hold them per market rather than assume one.
Supporter records and consent that holds
A supporter database in this sector is a consent database with contact details attached. Which channel a person agreed to, when, on which wording, and how to prove it are the fields that matter, because a regulator asking about marketing practice is asking about exactly those.
The same record frequently carries a donor, a volunteer, a campaigner and sometimes a beneficiary, which are four relationships with four different visibility rules. Merging them into one contact card with a role tag is how organizations end up sending a fundraising appeal to someone their support team is actively helping.
Programme delivery, volunteers and safeguarding
The delivery side is where the organization actually does its work and where software is usually weakest. Volunteer records carry background checks with expiry dates, training that has to be current, and assignment rules that must refuse to roster someone whose clearance has lapsed rather than warn about it.
Where the work involves children or adults at risk, safeguarding is a hard constraint: who can see a case, how a concern is escalated, what is retained and for how long, and an audit trail that a reviewer can follow. This is closer to a clinical system than to a CRM.
Grant management and funder reporting
Institutional funding arrives with a reporting schedule, a budget line structure that is the funder’s rather than yours, and conditions that must be evidenced. Most organizations meet this by exporting to a spreadsheet each quarter and reformatting it per funder, which consumes an astonishing amount of skilled staff time.
Building the funder’s structure into the fund model instead means the report is a query rather than a project. This is the phase where a non-profit platform pays for itself, and it is also the phase most often cut from scope because it is invisible to donors.
Field operations where connectivity is not assumed
For organizations working internationally or in rural settings, the platform has to work on a phone with no signal and reconcile when it returns. Offline-first is a data model decision rather than a caching layer, and it brings conflict resolution with it: two field workers editing the same beneficiary record a day apart both believe they are correct.
Device loss is the security case that matters here rather than server intrusion. Data on the handset has to be encrypted, scoped to the assignment, and remotely revocable.
Impact reporting, then a pilot rather than a launch
Impact measurement fails when it is added at the end, because the data required was never captured at the point of delivery. Deciding what the organization will claim, and instrumenting the delivery workflow to produce the evidence for it, belongs in the build rather than in a year-end report.
Rollout in this sector should be a pilot with one team or one region, because the users are frequently volunteers with varied confidence and limited time. A platform that a paid team would tolerate will simply not be used by a volunteer rota, and that shows up in a pilot rather than in a demo.
Where a restricted donation actually goes
The condition attached to a gift has to survive from the donation form all the way to the funder report, and most systems drop it at the first step.
The failure is rarely dramatic. Money arrives correctly, it is spent on legitimate charitable work, and the organization is entirely honest. But the link between the specific gift and the specific expenditure was never recorded, so proving the condition was met means reconstructing it by hand from bank statements and memory.
Almost every organization records the gift and its restriction correctly. Far fewer record which fund a specific payment drew from, and that single omission is what turns funder reporting into a quarterly reconstruction project rather than a report anyone can run.
Eight operators, eight different programmes
Non-profit is a legal status rather than a sector, and the organizations inside it do genuinely unrelated work. We mark what each one actually needs built.
The variable that decides the build is where the money comes from and who it answers to. An organization funded by many small regular donors needs supporter retention machinery. One funded by three institutional grants needs reporting infrastructure. One funded by membership dues needs a renewals engine. Those are three different platforms wearing the same charitable registration.
Public fundraising charities
Many small donors, recurring giving as the core asset, and retention economics closer to a subscription business than to anything else in this sector.
Custom build
Grant-funded NGOs
A handful of institutional funders, each with their own budget structure and reporting schedule. The reporting burden is the platform requirement.
Custom build
Foundations and grant-makers
Money flows outward instead of in. Applications, assessment, disbursement and grantee reporting, which is a different system entirely.
Custom build
Membership associations
Dues, renewals, member benefits and a directory. Commercially the closest thing here to a subscription SaaS product.
Custom build
Faith organizations
Regular giving, events, pastoral records and a volunteer base that overlaps heavily with the congregation. Data sensitivity is higher than it first appears.
Custom build
Social care and support services
Beneficiary case records, safeguarding, referrals and outcomes. Closer to a clinical system than to a CRM, and regulated accordingly in most markets.
Custom build
International development
Field operations with unreliable connectivity, multi-currency, local partner organizations and donor conditions that vary by country.
Custom build
Volunteer and community networks
Matching people to opportunities, clearance checks, rostering and hour tracking, where nearly every user is unpaid and occasional.
Custom build
None of the eight starts from a shipped platform, because we do not have one for this sector and adapting a commercial donation product to a fund-accounting obligation would be worse than starting properly. The capability below is what we bring instead.
How the work actually runs
Six stages. In this sector the pilot is not a formality, because the people who will use the system are frequently volunteers rather than staff.
Funding shape and obligations
Where the money comes from, what conditions attach to it, who the organization reports to and what its regulator expects. Trustees belong in this conversation because they carry the obligation.
Data protection position
What is held about supporters, volunteers and beneficiaries, who may see each category, how consent is recorded and how long anything is kept. Decided before the schema rather than audited after it.
Build giving and delivery together
The donation side and the programme side built as one system, so expenditure can draw from the fund that paid for it. Building them separately is what creates the reconciliation problem later.
Length varies by scopeReporting built as queries
Funder reports, trustee reports and regulatory returns produced from the system rather than assembled in a spreadsheet. This is the stage that returns staff time to the organization.
Migration from the spreadsheets
Almost every organization arrives with years of history in spreadsheets and a legacy database. Bringing it across with its restrictions intact is real work and we scope it honestly rather than describing it as an import.
Pilot with one team, then widen
Real volunteers on real devices doing real work, with training and a feedback route. What they cannot use gets changed before the organization commits to it.
What we bring to this sector
There is no ready-made product here, and we would rather say so than adapt a commercial donation platform and let it imply a fit.
What we bring instead is engineering that maps directly onto the problems above: fund-accounting ledgers from our financial work, offline-first field applications from our agriculture and logistics practice, case-record confidentiality from healthcare, and consent and retention handling from every regulated build we run. None of that is charity-specific software. All of it is the machinery a charity platform is actually made of.
We are also realistic about budgets. This sector is asked to spend as little as possible on overhead, which makes it exactly the wrong place for a large speculative build. We would rather scope a narrow first programme that removes one expensive manual process and prove it, than sell a platform that consumes a restricted grant.
What this sector requires
Funds modelled as funds
Restricted, unrestricted and designated money behaving differently, with expenditure drawing from the correct one. A category label on a single balance cannot enforce a donor’s condition.
Recurring giving that recovers
Card expiry is the largest single cause of lapsed regular giving. Retry logic, update prompts and a recovery sequence are worth more to most organizations than any acquisition feature.
Consent with a provable history
Which channel, when, on what wording, and how you would show it. A regulator asking about marketing practice is asking about exactly these fields.
Roles that do not merge
One person can be a donor, a volunteer and a beneficiary. Collapsing those into one contact record with a tag is how an appeal reaches someone your support team is helping.
Clearance that blocks rather than warns
Where volunteers work with children or adults at risk, an expired background check has to prevent rostering. A warning that can be dismissed is not a safeguarding control.
Reports that are queries
Funder structures built into the fund model so a quarterly report is run rather than assembled. This is where a platform in this sector actually pays for itself.
Want to talk through which single process is worth automating first?
Book a technical callBeneficiary data is the most sensitive data we handle
More sensitive than payment details, and frequently held by the organizations with the smallest security budgets.
A card number can be cancelled. A record showing that a named person used a domestic abuse service, sought addiction support, claimed asylum or received food aid cannot be undone once it is disclosed, and the consequences fall on someone who was already vulnerable when they asked for help. This is the strongest confidentiality case in anything we build, including healthcare and banking.
So the design assumptions change. Case data is visible to the people working the case rather than to everyone with a login. Exports are restricted and logged, because a spreadsheet emailed to a personal address is the realistic breach in this sector rather than an intrusion. Retention is enforced rather than aspirational. Field devices hold only the assignment, encrypted, and access can be revoked remotely when a phone is lost.
We will build whatever level of protection your beneficiaries need, and we will tell you where a convenient feature creates a disclosure risk that is not worth taking.
What a custom programme covers
The engineering practices behind every engagement in this sector, each with a team that does only that.
Fund accounting and ledgers
Restricted and designated funds with expenditure drawing correctly, multi-year pledges and balances trustees can see without asking finance to prepare them.
Fintech app developmentGiving, recurring gifts and receipting
Card retry and recovery sequences, multi-currency, offline and in-kind gifts, and tax receipting that follows the rules of each market rather than one.
Payment gateway developmentSupporter and case systems
Consent history, role separation, suppression, subject access requests, and case records whose visibility is scoped to the people doing the work.
Custom software developmentOffline-first field applications
Applications that work with no signal and reconcile with defined conflict rules, built from the same practice that runs our agriculture and logistics field systems.
React Native developmentMigration from spreadsheets and legacy systems
Years of history brought across with restrictions and consent intact, scoped honestly as the work it is rather than described as an import.
API developmentSecurity and data protection engineering
Access scoping, export controls, enforced retention, encryption on field devices and remote revocation, with the evidence a regulator or funder would ask to see.
Hire cybersecurity engineersNeed something this list does not cover?
Ask about custom workWhat a build in this sector actually covers
Three programme shapes, described by what gets engineered rather than by a metric we cannot show you the working for.
Public fundraising
Recurring giving with recovery
A giving platform where restricted gifts allocate correctly, failed renewals enter a recovery sequence rather than lapsing silently, and consent history is provable per channel. Retention economics are treated the way a subscription business would treat them.
Grant funded
Funder reporting as a query
The funder’s budget line structure built into the fund model, evidence attached to expenditure at the moment of spending, and quarterly reports produced by the system. The stage that returns skilled staff time to the organization.
Service delivery
Field casework with safeguarding
Offline-capable beneficiary records with conflict rules, case visibility scoped to the people working the case, clearance that blocks rostering rather than warning, and an escalation trail a reviewer can follow.
We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else’s.
Want to speak to a reference building something comparable?
Request a referenceWritten on this sector
Longer pieces on the problems above, written by the engineers who build these systems.
Why a restricted donation is not revenue
GivingCard expiry is the largest cause of lapsed regular giving
SafeguardingClearance that blocks rostering rather than warning about it
ReportingTurning the quarterly funder report into a query
Link targets resolve to the blog index while the sector pack is being assembled.
Want the whole set as a reading pack before your first call?
Request the packFinance spent three weeks a quarter rebuilding the same report, because nobody had recorded which fund each payment came out of.
The failure pattern this page is built around
In most sectors a missing field is an inconvenience. In this one it converts a report into a reconstruction project, quarter after quarter, consuming exactly the skilled staff time an organization has least of and can least justify spending on overhead.
Recording the fund at the moment of expenditure costs nothing during the build and is close to impossible to add afterwards, because the history it would need was never written down. It is the clearest example in this sector of a design decision that either saves an organization years of effort or does not.
Questions non-profit buyers actually ask
The twelve that come up on nearly every first call, answered the way we would answer them on the call.
Do we own the source code?
Yes, in full, on delivery. That matters more here than in most sectors, because it means a future funder or a change of supplier does not strand you.
Why is there no ready-made product for us?
Because fund accounting, safeguarding and funder reporting differ so much between organizations that a generic donation platform would fit the payment page and nothing behind it. We would rather say that than sell you an adaptation you fight for years.
We have a very small budget. Is this worth starting?
Possibly not as a full platform, and we will say so. The engagement we would suggest is narrow: pick the single most expensive manual process, usually funder reporting or recurring-gift recovery, build that well and measure what it returns. If it does not pay back, you have not spent a grant finding out.
Can you work with our existing accounting system?
Yes, and usually that is the right answer rather than replacing it. The fund model has to agree with the accounts, so we integrate and reconcile rather than duplicating a ledger your auditor already accepts.
What happens to our years of spreadsheets?
They get migrated with their restrictions and consent history intact, which is real work rather than an import. We scope it honestly and separately, because underestimating migration is the most common way a project in this sector overruns.
How do you handle beneficiary confidentiality?
Case data is visible to the people working the case rather than to everyone with a login, exports are restricted and logged, retention is enforced rather than advisory, and field devices carry only the current assignment, encrypted and remotely revocable.
Can volunteers actually use it?
That is what the pilot is for. Volunteers are occasional users with varied confidence, so a system a paid team would tolerate frequently goes unused by a rota. We test with real volunteers on their own devices before the organization commits.
Does it work without an internet connection?
Yes, where you need it to. Offline-first is a data model decision rather than a caching layer, and it brings conflict rules with it. We build this the same way we build agriculture and logistics field systems.
Can it handle tax receipting in our country?
Yes, and per market where you operate in several. Receipting is a legal instrument with rules that differ by jurisdiction, so it is held as configuration rather than assumed from one country’s model.
Can you build our grant application and assessment process?
Yes. Foundations and grant-makers run the flow in reverse - applications in, assessment, disbursement, grantee reporting - and it is a genuinely different system from a fundraising platform. We scope it as its own programme.
Do you offer non-profit pricing?
Ask us. We would rather have that conversation openly, with the scope narrowed to what actually returns value, than publish a discount and then propose more work than you need.
What is not included?
Your charitable registration and regulatory filings, payment provider onboarding, background-check provider contracts, and your own data protection policies and privacy notices. We build to whatever those require and will tell you where one of them changes the architecture.
Tell us what you are building.
There is no shipped product to adapt here, so this is a custom programme every time. We will tell you honestly how small the first one should be before you commit to anything.
A first call takes about thirty minutes and covers four things
Where the money comes from
Many small donors, a few institutional funders, membership dues or a mix.
What conditions attach to it
Restricted funds, funder reporting schedules and what you have to evidence.
Who you hold data about
Supporters, volunteers, beneficiaries, and how sensitive each of those is.
What runs today
The accounting system, the spreadsheets and whatever the team has quietly built.
Those four answers are usually enough for us to tell you which single process is worth automating first and roughly what it costs. If the honest answer is that a spreadsheet is serving you well enough for now, we will say that instead of scoping a platform against a restricted grant.
