Case study · Australian children's charity (anonymised)
Nonprofit · fundraising · Phased dashboard + integrations
One operational view for donors, pledges and finance
- nonprofits
- firebase
- stripe
- retool
- donors
An Australian children's charity ran pledges, payments and receipting across several tools. We centralised operational truth in an owned data layer and gave teams Retool dashboards instead of spreadsheet surgery before board packs.
Context
Fundraising ran through a mix of pledge capture, telemarketing workflows, card payments in Stripe, and portal activity. Finance needed auditable receipts. Leadership needed campaign and channel performance without waiting for another manual export.
No single SaaS product covered the whole journey, and the organisation rightly did not want donor history locked in a vendor UI nobody could extend. The goal was an owned system of record with clear roles: payments stay in the payment provider, stewardship and ops live in internal tools built on that core.
What hurt
- Pledges vs payments drifted. Pledge totals in one place rarely matched settled transactions after refunds and partial fulfilment.
- Receipting and CRM updates were fragile. When an automation missed, donor services re-keyed data under time pressure.
- Reporting before board meetings was manual. Several CSVs became one deck; one broken formula changed the story.
- Access and privacy were unclear. Sensitive donor data sat across logins without a crisp map of who should see what.
Approach
We modelled donors, pledges, payments, campaigns and receipts in Firestore as the operational backbone. Cloud Functions handled payment events, PDF receipt generation, light donor matching rules, and sync into the structures teams already searched in Retool.
Retool became the day-to-day console: pledge and payment queues, exception lists, finance views, and leadership summaries. Executive views reused the same facts as ops, so nobody was arguing from different extracts.
Stripe remained the compliance anchor for card data while the owned layer stored the business objects the charity needs to run programs and stewardship. We documented which fields staff may edit and which fields only automation may touch.
What improved
- One place to answer “what did we raise, after refunds, for this appeal?”
- Fewer nights lost to reconciliation spreadsheets before governance meetings.
- Clearer role boundaries for donor data and fewer mystery exports living on laptops.
- A path to add new channels without rewriting the whole CRM each time.
Lessons you can reuse
Start from reporting questions, not tool logos. If you cannot state the board pack metrics in one sentence each, the schema is not ready.
Automate receipts and status, not judgement calls. People still own relationships; systems own deterministic updates from payments.
If your sprawl is earlier stage, When Stripe and your CRM disagree and Spreadsheet reconciliation describe the same failure modes in smaller shops.