Web Design & Development for Nonprofits
Follow an illustrative nonprofit website project from leaky donation form to measured result, with the rules, calendar, costs and briefing that shape it.
Last revised
Web design & development for nonprofits is a different job from building a store or a brochure site. A nonprofit website has to raise money, recruit volunteers, fill events, report on impact and satisfy a board, all while being run by a small team that also does everything else. The site that works is the one with a donation flow that works, recurring giving that donors actually choose, program and impact pages that make the case for support, volunteer and event signup that feeds straight into the tools staff already use, and a content structure a communications lead can maintain between campaigns without calling a developer.
This page is for executive directors, development directors, communications managers and board members who are weighing a rebuild or a significant overhaul. It explains the problems specific to the sector, the rules that shape a donation page, the calendar that dictates when anything can ship, the deliverables worth paying for, how a project runs from discovery to launch, what drives cost, how to brief a supplier and how to measure whether the work paid off. To make that concrete, it follows one illustrative project for a typical small nonprofit from problem to measured result. That project is a composite example written for this guide, not a client story, and every number in it is illustrative.
The underlying position is simple. Every dollar spent on overhead is scrutinized, by donors, by funders and by the board, and donation conversion is the whole game. A nonprofit site earns its cost back when more of the people who arrive intending to give actually complete a gift, and when more of those gifts are monthly. Everything else on this page serves that outcome or protects the organization while pursuing it.
What nonprofits are dealing with online
Most nonprofit sites were not designed so much as accumulated. A founder commissioned a site years ago, a volunteer added pages, a grant paid for a microsite, a donation platform was bolted on with its own look, and an events tool lives on a third domain. The result usually shares a handful of problems, and it helps to name them before talking about solutions.
The donation path leaks
The donate button often leads to a third-party form with a different design, a different domain and more fields than the gift requires. Donors hesitate when the page looks unfamiliar, when they are asked for a phone number with no explanation, or when they must create an account before giving. Every field between intent and confirmation costs completed gifts, and the donation page is the one place on the site where that loss is directly measurable. If you can count visits to the form and completed gifts, you can count the leak.
Recurring giving is an afterthought
Monthly donors are the most valuable relationship a small nonprofit has, because they fund operations predictably and they tend to stay. Yet many forms default to a one-time gift, bury the monthly option in a dropdown, or offer it only after the one-time gift is complete. A form that presents monthly giving as an equal first choice, with an amount ladder that makes sense for a monthly commitment, changes the mix of gifts without changing the traffic.
Impact is described, not shown
Program pages frequently read like grant narratives: accurate, dense and written for a program officer. Individual donors respond to specific outcomes, real people (with consent), and a clear link between a gift and what it pays for. This is where storytelling video and photography earn their place, and where a well-structured impact page does more work than a long history of the organization.
The site is hard for a small team to run
When publishing a news item or adding an event requires a developer, the site goes stale between campaigns. Stale sites look abandoned to a first-time donor. The build has to be judged as much by what the communications lead can do alone on a Tuesday afternoon as by how it looks on launch day.
Accessibility is an obligation and a courtesy
Nonprofits serve the public, often including people with disabilities, older donors and people using older phones on slow connections. Accessible communications are part of the mission, and for organizations that receive federal funding they are also a legal obligation, covered in the regulatory section below. Our separate guide to performance and accessibility for nonprofits goes deeper on testing and remediation.
The illustrative project: a regional food bank's starting point
To keep the rest of this page grounded, here is the example we will follow. It is illustrative: a composite of the situation many small and midsize nonprofits describe, with numbers invented for teaching purposes and labeled as such.
The organization is a regional food bank with a staff of about a dozen, one of whom is responsible for communications, digital and events. It raises most of its individual giving online, and like most of the sector it relies heavily on year-end giving. The site runs on an older content management system that only one former volunteer understood. The donation form is hosted by a payment platform on a separate domain, asks for eleven fields, defaults to a one-time gift and shows monthly giving as a checkbox below the card fields. Volunteer signup is a PDF to download and email back. Events use a ticketing site with no link back to the organization's own pages.
The executive director's brief to the board is one sentence: raise more from the people who already visit, and stop depending on one volunteer to keep the site alive. The board's finance committee adds its own condition: the spend must be justified in terms of gifts, not design.
Before any design work, the team pulls a baseline from the previous year's analytics and the payment platform's reports. In this illustrative case the donation form received about 6,000 visits over the year-end period, and about 180 in every 1,000 of those visits ended in a completed gift, so roughly 1,080 gifts. Of those completed gifts, about 60 in every 1,000 were set up as monthly. Volunteer applications arrived at a rate of a few per week, and the communications lead spent a morning each week re-keying PDF forms into a spreadsheet.
Those before-and-after figures are the destination of the example, shown up front so you can see what the project was designed to move. The rest of the page explains how each number is reached, and why the last one matters as much as the first three.
The rules that shape a nonprofit donation page
A commercial checkout answers to payment rules and consumer protection law. A donation page adds a layer of charity regulation that designers and developers rarely think about, and it has consequences for what the site says and where it asks. What follows is a practical note, not legal advice; your counsel or a charity-registration specialist should confirm how it applies to your organization.
Charitable solicitation registration
State charitable solicitation registration governs where an organization may ask for donations, and a public donate button reaches every state. Most states require charitable solicitation registration before you fundraise in them. Online giving can trigger that requirement in states whose residents you target, or from which donations arrive on a repeated and ongoing basis or in substantial volume. The Charleston Principles, a set of guidelines adopted by state charity regulators through the National Association of State Charity Officials, set out how regulators usually read internet solicitation: a website alone does not generally require registration everywhere, but specifically targeting a state's residents, or receiving contributions from a state regularly or in volume, can.
For the website, this has three practical consequences. First, targeted campaigns, including paid ads geotargeted at a state and emails to lists concentrated in one, should be checked against where the organization is registered. Second, many states require specific disclosure statements on solicitation materials, and a common pattern is a state disclosures page linked from the donation form and the footer, so the language can be updated without redesigning the form. Third, the donation platform's reports should be able to show gifts by donor state, so the development team can see when a state is becoming a regular source of donations and raise the question of registration.
Acknowledgments and quid pro quo disclosure
The IRS governs written acknowledgment and quid pro quo disclosure for contributions. In practice, a donor generally needs a contemporaneous written acknowledgment from the charity to deduct any single contribution of $250 or more, stating the amount and whether the donor received goods or services in return. When a donor pays more than $75 and receives something in return, such as a gala dinner or a premium, the charity must provide a written disclosure explaining that only the amount above the fair market value of what was received is deductible, along with a good-faith estimate of that value. For the website, that means the receipt email the donation platform sends is a compliance document, not just a thank-you: its wording, its fields and its handling of event tickets and premiums need to be designed with the finance team, not left at the platform's default.
Accessibility under Section 504
A program that receives federal funding takes on accessibility obligations under Section 504 of the Rehabilitation Act, which prohibits disability discrimination by recipients of federal financial assistance. Websites and digital services are part of how a recipient delivers its programs. The technical standard that recent federal accessibility rules reference is the Web Content Accessibility Guidelines, WCAG 2.1 at Level AA, and it is the sensible working target for any nonprofit site, federally funded or not. That covers color contrast, keyboard operation, form labels and error messages, captions for video, text alternatives for meaningful images and a logical heading structure. Check the specific requirements your funding agency has published, since they can set their own dates and details.
Payments and donor data
Card data should never touch the nonprofit's own server. Using a payment processor's hosted fields or embedded checkout keeps the card number on the processor's systems, which keeps the organization's PCI DSS obligations as small as they can be and removes a whole category of risk from the website. Donor records themselves, names, addresses, giving history, belong in the donor database or CRM, with the website passing data to it rather than holding a second copy. A privacy policy that says what the organization collects, why and who it shares it with is the minimum; a nonprofit that sells or exchanges lists should say so plainly.
Watch for: the rules above are the ones that most often surprise nonprofit web projects. They are summarized here so you can ask the right questions, not so a supplier can answer them for you.
- A geotargeted campaign aimed at a state where the organization is not registered.
- A receipt email that omits the value of goods or services received for event tickets and premiums.
- A donation form or video that fails basic accessibility checks in a federally funded program.
- A custom form that captures card numbers on the organization's own server.
The nonprofit calendar: when work can happen and who signs it off
End-of-year giving decides the budget. December traffic is a large share of annual revenue for most organizations that fundraise from individuals, and the last days of the month concentrate it further. Giving Tuesday, which falls on the Tuesday after US Thanksgiving, opens the season for many. That calendar has a firm consequence for web projects: nothing risky ships in November. A new donation form, a change of payment processor, a new CMS or a redesigned homepage all need to be live, tested and proven by the end of October, with November reserved for campaign content, not engineering.
Working backward, a project that must be proven before year-end usually wants discovery in late spring or early summer, design over the summer and build in early fall, with a live period in October to shake out problems while traffic is moderate. Projects that miss that window should usually aim for a launch in late January or February, after the year-end receipts have gone out and the finance team has closed the year, rather than squeezing a launch into December.
Other seasons matter too. Spring galas and runs drive event registrations, and the site needs its event pages and ticketing ready weeks in advance. Grant cycles bring reporting deadlines when program staff have no time for content reviews. Summer is quieter for many organizations and is often the best window for the content work a rebuild demands.
Approvals take longer than the build
Who signs it off shapes the schedule as much as what is built. An executive director approves, and often a board committee does too, which makes the approval cycle longer than the build. Board committees meet monthly or quarterly, and a design that needs committee sign-off can wait weeks for a meeting. The fix is to agree in writing at the start which decisions need the committee (budget, brand direction, the donation platform, privacy policy), which need only the executive director, and which the communications lead can make alone. Then schedule the committee decisions around the meeting calendar rather than hoping a meeting falls at the right moment.
| Period | What the website work should be doing | What to avoid |
|---|---|---|
| January to February | Close the year, review year-end data, write the brief, run discovery | Launching anything while receipts and acknowledgments are going out |
| March to May | Discovery, content audit, platform decisions, committee approvals | Starting design before the donation platform is chosen |
| June to August | Design, content writing, photography and video planning | Leaving program content to the last month |
| September to October | Build, testing, launch, live monitoring at moderate traffic | Launching later than mid-October if year-end matters |
| November to December | Campaign content, small copy changes, monitoring | New forms, new processors, new templates, plugin updates without testing |
Deliverables that earn their place on a nonprofit site
A nonprofit site does not need everything a commercial site might have. It needs a small number of things done properly. In the illustrative project, the scope was set by asking of every proposed deliverable: does this help someone give, volunteer, attend or trust us, and can the team run it afterward?
The donation flow
This is the center of the project. A good nonprofit donation flow has a clear choice between monthly and one-time giving presented as equals, an amount ladder with a sentence of impact beside each amount where the organization can truthfully say what a gift does, a custom amount field, the fewest fields the payment and the acknowledgment genuinely require, digital wallets where the processor supports them, an optional field to cover processing fees if the organization wants one, a tribute or memorial option if donors ask for it, and a confirmation page and receipt that say thank you properly and meet the acknowledgment rules. The form should load on the organization's own domain and look like the rest of the site. Treat it like any conversion page; the principles in our practical guide to landing page design apply directly to campaign-specific donation pages.
Program and impact pages
Each program gets a page that answers four questions in order: what problem does it address, what does the organization do about it, what has changed as a result, and how can a reader help. Impact figures should come from the organization's own reports and be dated. Storytelling video and photography sit here, with captions, consent recorded, and a transcript for video. If the organization is investing in film, our page on video editing and production for nonprofits covers how to plan footage that can be cut for the site, social and the annual appeal from the same shoot.
Volunteer and event signup
Volunteer applications should be a web form that writes directly to the volunteer management tool or CRM, with the questions the volunteer coordinator actually uses to place people and nothing more. Event pages should live on the organization's domain, with ticketing embedded or linked in a way that returns people to the site afterward and handles the quid pro quo disclosure for tickets that include dinner or other benefits.
Annual report design
The annual report is often the most-read document a nonprofit publishes after its donation page, and it increasingly works better as a set of web pages than as a PDF. A web annual report can be read on a phone, is accessible when built properly, can be linked to section by section in appeals, and can still be printed. Where a PDF is required for funders, produce it from the same content and make it an accessible PDF, not a scan.
A content system the team can run
The CMS should let staff publish news, events, program updates and campaign pages from a small set of templates without breaking the design. Design tokens (named values for color, spacing and type) make that safer, because a staff member choosing a button color picks from a controlled palette rather than a color wheel, and they let the developer change a value once and have it update everywhere. The visual identity those tokens encode may itself need attention, which is the subject of our page on brand and identity design for nonprofits.
Integrations
The site sits between the donation processor, the donor database or CRM, the email platform, the volunteer tool and analytics. Each connection needs a documented owner, a documented data flow and a test. The goal is one record per supporter in the CRM, updated by the site, rather than parallel spreadsheets.
How the illustrative project ran, step by step
The food bank's project ran over roughly five months from signed brief to launch, timed to go live in early October. The durations below are illustrative of this example, not a standard lead time; your own schedule depends on scope, content readiness and how often your approvers meet.
- Baseline and discovery The team exported a year of analytics and donation data, mapped every place a supporter could give, volunteer or register, and interviewed the executive director, development lead, volunteer coordinator and two board members. Discovery produced a single-page problem statement, a list of integrations and a measurement plan. Our guide to getting discovery for web projects right covers what that phase should produce.
- Donation platform decision Before any design, the team confirmed the payment processor and donor database, because the form's capabilities (embedded fields, wallets, recurring management, receipt templates) set what design could promise. The board finance committee approved the platform at its scheduled meeting.
- Content audit and structure Every existing page was marked keep, rewrite, merge or delete. The site shrank to a structure built around Give, Volunteer, Get Help, Our Programs, Impact and About, with events and news as supporting content types.
- Donation flow prototype The form was prototyped first and tested with a handful of real donors and staff on phones, before the rest of the site was designed. Fields fell from eleven to six for a card gift by removing a title field, a phone number, a how-did-you-hear question and two marketing checkboxes that the email platform could handle after the gift.
- Design and accessibility review Page templates were designed against WCAG 2.1 AA from the start, with contrast checked on the palette and keyboard paths checked on every interactive component. The executive director approved templates; the committee approved only the homepage direction.
- Build and integrations Templates were built in the CMS, the donation form embedded on the organization's domain, volunteer and event forms connected to the CRM, and receipt emails rewritten with the finance lead to meet acknowledgment and quid pro quo requirements.
- Testing and launch Test gifts were run on every combination of one-time and monthly, card and wallet, with and without tribute, on current phones and an older one. The site launched in early October and ran at normal traffic for four weeks before Giving Tuesday.
- Freeze, monitor, measure From November 1 the site was under a change freeze except for campaign copy. After year-end, the team compared the new period against the baseline and wrote a short report for the board.
Two decisions in that sequence did most of the work. Choosing the donation platform before design prevented the most common rebuild failure, a beautiful form mockup that the processor cannot deliver. And prototyping the form first meant the highest-value page got the most testing time rather than whatever was left at the end.
What goes wrong, and what to do instead
The failures on nonprofit site projects repeat with depressing regularity. Most come from treating the site as a brochure rather than as the organization's main fundraising channel.
A donation flow with too many steps
Avoid a donation flow with too many steps. Every field between intent and confirmation costs completed gifts, and this is the one page where that is measurable. Multi-page forms, mandatory account creation, an interstitial asking the donor to confirm before paying, and a redirect to an unfamiliar domain all add friction. Instead, keep the card gift on one screen where possible, ask only for what the payment and acknowledgment require, and move everything else (interests, how the donor heard about you, communication preferences) to the confirmation page or a later email where declining costs nothing.
Launching in November
A late project drifts into November, the team decides to launch anyway because the old site is embarrassing, and a payment integration fails on Giving Tuesday. The old site is embarrassing; it also works. Hold the launch until the new year if October is missed.
Designing for the board instead of the donor
Board members are important readers, but they are not the audience that funds the organization online. Homepages crowded with every program because each has a champion on the board serve nobody. Agree in the brief that the homepage has one job, getting a new visitor to understand the mission and give, and that program pages carry the detail.
Building something only a developer can run
A custom-coded page for every campaign looks impressive and leaves the team dependent on a developer for every appeal. Build campaign templates the communications lead can duplicate and edit. Ask for handover documentation that a new staff member could follow; it should cover publishing, the donation form settings, integrations, credentials ownership and the update routine.
Tip: run a test gift on the live site on the first day of every month, one-time and monthly, on a phone. It takes ten minutes, it catches expired API keys and broken receipts before donors do, and the refunds cost nothing but a few minutes of the finance team's time.
What drives the cost of nonprofit web design and development
Web design and development work starts at $4,800.00 per project with us. The pricing page puts every rate next to what the US market typically charges, and a quote turns the range into one number for your volume. That figure is a starting price, not a typical total: where a given project lands depends on the factors below.
Number of templates, not number of pages
A site with two hundred news items and ten templates costs far less to build than a site with forty pages that are each designed individually. Scope by template: home, program, impact story, event, news item, campaign donation page, volunteer form, standard content page, and a small number of special cases.
The donation and CRM integration
Embedding a well-documented processor's form on a standard CMS is modest work. Building a custom donation experience against a processor's API, syncing recurring gift status to a CRM, or migrating recurring donors from one processor to another is substantially more, and the last of those carries real risk to income. Migration of recurring gifts deserves its own line in any quote.
Content readiness
The most common reason nonprofit projects run over is not development. It is content that does not exist yet: program pages that need writing, photography that needs consent, impact figures that need a program manager's sign-off. Budget for writing and for staff time, or scope a smaller launch.
Accessibility and performance
Building to WCAG 2.1 AA from the start adds little to a project. Retrofitting it after launch, or remediating a large set of legacy PDFs, adds much more. A federally funded program should price accessibility testing explicitly rather than assuming it is included.
Approvals and meetings
Every committee review cycle adds calendar time and supplier time. A clear decision map at the start keeps this under control.
| Cost driver | Pushes cost down | Pushes cost up |
|---|---|---|
| Templates | A small, reusable set | Bespoke design for each page or campaign |
| Donation platform | Embedded form from an established processor | Custom API build, recurring-donor migration |
| CRM and email | One-way sync using standard connectors | Two-way sync, custom fields, data cleanup |
| Content | Written, approved and consented before build | Written during build, approvals pending |
| Accessibility | Designed in from the first template | Retrofit or large document remediation |
| Approvals | Decision map agreed at kickoff | Committee review of every template |
Estimates are only as good as the scope behind them. Fixed quotes on vague briefs tend to go wrong, so ask suppliers to price the uncertain parts, such as recurring-donor migration or data cleanup, as separate lines.
How to brief a web supplier for a nonprofit project
A good brief does most of the work of choosing a supplier, because it forces each one to respond to the same problem. For the illustrative food bank, the brief ran to about three pages and covered the following.
- The problem in one paragraph: what is not working, with the baseline numbers the organization has, such as donation-form visits, completed gifts and the share of monthly gifts expressed as a rate per 1,000.
- The outcomes wanted: more completed gifts per 1,000 form visits, more monthly gifts per 1,000 gifts, volunteer applications arriving in the CRM, and a site the communications lead can run.
- Existing platforms: the payment processor, donor database, email tool, volunteer tool and CMS, and which of them are fixed and which are open to change.
- Constraints: the launch window before November, the change freeze, the approval map, WCAG 2.1 AA as the accessibility target, and any federal funding that brings Section 504 obligations.
- Content status: what exists, what needs writing, what photography and video is available with consent.
- Budget range: an honest range lets suppliers propose the right scope instead of guessing.
- What happens after launch: who will run the site, what support is wanted, and how updates to plugins and the CMS will be handled.
When evaluating responses, look for suppliers who ask about the donation platform and the calendar before they talk about design. Our checklist of questions to ask before hiring a web design agency is a useful starting point. If you would rather judge the work than the pitch, you can send a couple of your own files and see how they come back.
Measuring the result: gifts, not page views
The finance committee's condition, justify the spend in gifts, is the right one. A nonprofit site should be measured against the outcomes in the brief, using the same definitions before and after.
The core measures
- Donation form completion rate: completed gifts per 1,000 visits to the donation form, measured over comparable periods (year-end against year-end, not October against December).
- Recurring share: monthly gifts per 1,000 completed gifts, and the number of active monthly donors at the end of each quarter.
- Form abandonment by field: where analytics allow it, which field donors stop at. This is what tells you which field to remove next.
- Volunteer and event conversion: completed applications and registrations per 1,000 visits to those pages, and whether they arrive in the CRM without re-keying.
- Accessibility: automated checks on every template, plus a manual keyboard and screen reader check of the donation flow each quarter.
- Staff time: how long it takes to publish a news item or a campaign page, and how often a developer is needed.
How the illustrative project measured out
In the illustrative example, year-end visits to the donation form were close to the previous year's, about 6,000. Completed gifts rose from about 180 to about 260 in every 1,000 visits, which at that traffic is roughly 1,560 gifts instead of roughly 1,080, an increase of about 480 gifts from the same number of visitors. Monthly gifts rose from about 60 to about 140 in every 1,000 completed gifts, so roughly 218 new monthly donors instead of about 65. Volunteer applications arrived directly in the CRM, which returned the communications lead's weekly morning of re-keying. Three staff members, rather than one former volunteer, could now publish pages and edit the donation form's amounts. And nothing risky shipped in November.
Those numbers are illustrative, and you should not expect any particular result from a redesign. The point of the example is the method: measure the same things the same way before and after, over comparable periods, and report them in the terms the board uses.
Attribution needs care. A stronger appeal letter, a matching gift or a news event can move year-end giving by themselves. Compare the form's completion rate, which the site controls, rather than total revenue, which it does not. If the organization also changed its email program in the same year, say so in the report.
A nonprofit website is judged by one number more than any other: how many of the people who arrive intending to give actually complete a gift.
Keeping the site working between campaigns
A launch is the start of the site's working life, not the end of the project. The organizations that keep their gains do a small amount of maintenance on a steady rhythm.
A monthly routine
Run a test gift, one-time and monthly. Check that receipts arrive and read correctly. Review the form's completion rate against the same month last year. Apply CMS and plugin updates on a staging copy first, never in November or December. Check the volunteer and event forms still write to the CRM.
A quarterly routine
Run an accessibility check on the donation flow and any new templates. Review donor-state reports with whoever manages charitable solicitation registration. Refresh impact figures on program pages with dated numbers from the latest report. Remove events and campaign pages that have ended, or move them to an archive.
An annual routine
Before the fall, review the year-end campaign pages and the receipt templates with the finance team, confirm the change freeze dates, and make sure more than one person on staff can publish, edit the donation form's amounts and pull the donation report. After year-end, write the short measurement report for the board and decide the next improvement. Often it is a single change to the form, tested properly, rather than another redesign.
If the next priority is the experience rather than the build, such as the information architecture, the donation journey across devices or the volunteer path, our page on UI and UX design for nonprofits covers that work in more depth.
Verdict A nonprofit website is worth rebuilding when the donation flow leaks, recurring giving is buried or the team cannot run the site alone, and it pays back through more completed gifts from the visitors you already have. Choose the donation platform before design, prototype the form first, build to WCAG 2.1 AA, respect the charitable solicitation and IRS acknowledgment rules, launch by October and freeze in November, then measure the form's completion rate the same way before and after.
Related
Other work for nonprofits
- Performance & Accessibility for Nonprofits
- Brand & Identity Design for Nonprofits
- UI & UX Design for Nonprofits
- Video Editing & Production for Nonprofits
Web design & development in other sectors
- Web Design & Development for Food and beverage
- Web Design & Development for Pet products
- Web Design & Development for Toys and games
- Web Design & Development for Consumer electronics
More on web design & development
- How the work runs, what it costs and how we check it
- Project Handover Documentation: What Actually Works
- Time Series Data Storage, Done Properly
Trying us out
The quickest way to find out if we are any good for you is to send a couple of your own files and look at what comes back. It is free and there is no card involved. If the scope is already clear, ask for a fixed price instead.