How to Build an App Like Donorbox: Nonprofit Donation Management

Donorbox charges 1.5% of every donation. That sounds small. At $1M/year in donations, it's $15,000. At $5M/year, the monthly cap kicks in at $1,500 and the annual total is $18,000. And that $18,000/year buys you a product you don't control, on infrastructure you don't own, with donor data that sits in Donorbox's database.

For small nonprofits running occasional campaigns, Donorbox makes sense. For a hospital foundation running $3M annual fund campaigns, a community foundation managing 40 named funds, or a national membership organization with chapter structures, the math shifts. The product should be yours.

Here's what it takes to build one.

Who builds a custom donation management platform

The organizations most likely to commission a custom build share a few traits. They raise more than $1M/year. They have existing CRM infrastructure (Salesforce, Raiser's Edge, or a custom donor database) that needs real-time integration. And they care about the donor relationship enough to want full control over the experience from first visit to year-end receipt.

Hospital and university foundations are the clearest case. A hospital foundation raising $5M/year pays $18,000 to Donorbox annually. A custom platform costs more upfront but pays back within 2-3 years, and gives the foundation a branded giving experience that fits their capital campaigns and named endowment structures.

Community foundations managing multiple named funds need fund-specific routing. A donor gives to the "Smith Family Education Fund" and the gift routes to that specific accounting line. Donorbox's campaign model doesn't map cleanly to fund accounting structures.

Religious organizations (church giving apps) need mobile-first checkout, offline giving sync (for in-person collections), text-to-give, and giving categories (tithes, building fund, missions). These requirements are niche enough that generic platforms handle them poorly.

Membership organizations that fundraise alongside dues collection need a unified payment surface. The member renews their membership and makes an annual fund gift in one checkout. Two separate platforms create friction and duplicate data.

The embeddable donation form

The donation form is the product's distribution mechanism. It lives on the nonprofit's existing website as an embedded widget (iframe or a lightweight JavaScript snippet that renders inline). The form must load in under 1 second. If you embed a 400KB JavaScript bundle into a 10-year-old church website, it breaks the page layout and donors leave.

The form collects: donation amount (suggested amounts plus custom field), giving frequency (one-time, monthly, quarterly, annually), dedication (in honor or in memory of someone), donor contact information (first name, last name, email, optional phone and address), and payment method.

Suggested amounts are configurable per campaign. A hospital capital campaign might suggest $500, $1,000, $2,500, and $5,000. An annual fund campaign might suggest $100, $250, $500, and $1,000. Let the campaign administrator set these from the dashboard, not from a configuration file.

Giving frequency should default to monthly for new visitors. Monthly giving programs are the highest-return feature on the form. A donor who clicks "monthly" instead of "one-time" is worth 10-12x more over 3 years. Make "Monthly" the pre-selected option, with "One-time" available as an alternative.

The form also needs a standalone donation page (for direct-link campaigns, email appeals, and social media) and a mobile-optimized layout that works on a phone screen without horizontal scrolling.

Recurring giving: the engine underneath

Recurring giving runs on Stripe Subscriptions. The donor enters their card, selects a frequency, and Stripe charges automatically.

When a payment fails, the dunning sequence kicks in automatically: Stripe retries the charge three times over five days. On the fourth failure, your system sends an email to the donor with a link to update their card. If the card remains invalid for 30 days, the subscription is paused and the donor record is flagged as lapsed.

Dunning emails are not optional. Lapsed recurring donors are your most recoverable segment. A personalized email ("Your monthly support of the pediatric ward has lapsed") recovers 20-40% of failed subscribers when sent within 48 hours of the first failed charge.

Stripe sends webhook events for every charge event: successful payment, failed payment, card updated, subscription canceled. Your platform must consume these webhooks and update donor records in real time. If a donor's card is charged on the 15th, their giving history must show that charge by the 16th. Stale records create support tickets.

Annual giving society tiers add one layer of logic: a donor who gives $1,200 or more in cumulative gifts over a calendar year qualifies for the "Sustaining Supporter" tier. Tiers are calculated on a rolling 12-month window, not a calendar year, to avoid mass tier drops every January. The algorithm runs nightly as a background job against the giving history table.

Donor management: the CRM layer

The donor CRM is what separates a payment processor integration from a donor management platform.

Every donor has a profile. The profile shows their full giving history (every gift, amount, date, campaign, frequency), contact information, communication preferences (email opt-in, mail opt-in, phone opt-in), and any notes from the development team ("Met at the gala, interested in naming a room in the new wing").

Household giving combines spouses. If John Smith and Jane Smith both give, their combined giving counts toward household totals and giving society tiers. This matters for major gift cultivation: a couple giving $5,000/year combined is a different prospect than two individuals each at $2,500. The household model requires a relationship link between donor records.

Soft credit is a common nonprofit accounting concept that most platforms ignore. A foundation board member solicited a $10,000 gift from a friend. The friend made the gift directly to the foundation. The board member gets "soft credit" for the gift in the foundation's tracking system because they were the solicitor. Soft credit doesn't affect the foundation's accounting, but it does affect solicitor performance tracking and cultivation strategy.

Giving history should display as a timeline, not a table. The most recent gift shows at the top. Each entry shows the amount, campaign, date, and frequency. The timeline view makes it easy for a development officer reviewing a donor profile to understand the relationship at a glance.

Tax receipts: the legal requirement

For donations to a 501(c)(3) nonprofit, the IRS requires written acknowledgment for every gift of $250 or more. Best practice (and what donors expect) is a receipt for every gift, regardless of amount.

The receipt email must arrive within 30 minutes of the gift. Donors who give online check their email immediately. A receipt that arrives the next day creates doubt about whether the transaction completed.

The receipt must contain: the nonprofit's legal name, the EIN, the gift amount, the gift date, the campaign or fund name, the statement "No goods or services were provided in exchange for this contribution," and the nonprofit's mailing address. Missing any of these makes the receipt non-compliant.

PDF generation is required. Donors need a printable record for tax filing. Use Puppeteer (headless Chrome rendering an HTML receipt template to PDF) or pdf-lib (programmatic PDF generation). Puppeteer produces better-looking receipts. pdf-lib is lighter and faster. Both work.

Year-end summaries aggregate all giving for the calendar year into a single letter. The letter lists every gift with amount and date, shows the total annual giving, and includes the same legal statement. These go out by January 31 for the prior year. Automate the generation and delivery. Sending year-end letters manually at scale is a 3-day staff effort. Automated delivery takes 30 minutes.

Fundraising campaigns

Campaigns organize giving by purpose. The annual fund is a campaign. The capital campaign for the new pediatric wing is a campaign. The end-of-year matching gift push is a campaign.

Each campaign has a name, description, a goal amount, a start date, and an end date. The campaign dashboard shows total raised against goal, number of donors, average gift size, and a giving timeline chart.

Donations route to campaigns at time of checkout. If a donor gives through the pediatric wing campaign page, the gift is attributed to that campaign. If they give through the general donation form, they choose a fund from a dropdown. Campaign attribution is the foundation of the reporting layer.

The campaign dashboard also shows donor acquisition source: where did this donor first encounter the organization? Email appeal? Social media post? Direct mail? Google search? This requires UTM parameter tracking on donation form loads. When a donor clicks through from an email with ?utm_source=email&utm_campaign=annual-fund-2026, that attribution follows the gift into the database.

Peer-to-peer fundraising

Board members and volunteers create personal fundraising pages on behalf of the nonprofit. The volunteer sets a personal goal, shares their page link with their network, and donors give to the volunteer's page. Gifts route automatically to the nonprofit. The volunteer sees their personal fundraising total in a lightweight dashboard.

This model works well for events (a board member running a race), challenges (a volunteer doing a 30-day fitness challenge), and personal milestones (asking for donations instead of birthday gifts).

The peer-to-peer page inherits the nonprofit's branding. The volunteer can add a personal photo and a personal message, but the organization's name, logo, and tax information are fixed. Donors see exactly who their money goes to.

Reporting: what development teams actually need

LYBUNT is the most valuable report for working development teams. It answers the question: who gave last year and hasn't given yet this year? The query compares giving records across two fiscal year windows and produces a contact list. When exported to CSV, it goes directly into the team's email outreach tool for the re-engagement campaign.

The major gift prospect report surfaces donors who have given three or more consecutive years. Consistent multi-year giving is the strongest predictor of major gift potential. A donor who gave $500, $600, and $750 in three consecutive years is a meaningful prospect for a $5,000 ask. This report saves development officers 10-20 hours of manual spreadsheet analysis per campaign cycle.

Tech stack

React handles the donation form widget (rendered as a standalone JS bundle), the donor-facing pages, and the admin dashboard. Node.js powers the API. PostgreSQL stores donor records, giving history, campaign data, and recurring giving subscriptions.

Stripe covers one-time donations (Stripe Elements embedded in the form), recurring giving (Stripe Subscriptions), and nonprofit payouts if the platform also distributes funds to chapter organizations (Stripe Connect). SendGrid handles donation receipt emails, dunning emails, year-end summaries, and campaign update notifications.

Puppeteer (or pdf-lib) generates tax receipt PDFs on demand and in batch for year-end letters.

Build timeline and cost

Total timeline: 8-12 weeks. Cost: $80K-$130K.

The lower end of the range covers a solid MVP with the embeddable form, one-time and recurring giving, donor CRM, tax receipts, and LYBUNT reporting. The upper end adds peer-to-peer fundraising, advanced fund routing for community foundations, Salesforce or Raiser's Edge integration, and chapter-level reporting for national organizations.

What most donation platforms get wrong

The three most common failure points in custom donation platform builds:

The embeddable widget is slow. A 500KB JavaScript bundle embedded into a church website with a 2011 WordPress theme will break the page layout and slow the page load. The widget should be under 50KB, render inline without reflowing the host page, and work in Internet Explorer 11 if your donor base is older than 65.

Tax receipts are manually assembled. Most early builds automate email receipts but manually assemble year-end summaries using spreadsheet exports. When the organization reaches 5,000 donors, this becomes a 3-day annual exercise. Build automated year-end letter generation from the start.

Recurring giving metrics are not tracked. The platform processes recurring gifts but doesn't report on them. Development teams can't see total monthly recurring revenue, active subscriber count, average recurring gift size, or churn rate. These metrics are essential for understanding the health of the recurring program. Build a recurring giving dashboard alongside the campaign dashboard.

If you're scoping a donation management platform for a nonprofit or foundation, a 2-week discovery sprint is the right first step. It maps your fund structure, donor data model, CRM integration requirements, and compliance needs, then produces a technical specification and milestone plan before any code is written.