What a nonprofit app costs, and how to put it in a grant budget
$35,000 – $54,000 for an app your people and volunteers use, with donations in it and a page staff can post from. $39,000 – $59,000 if it has to meet the accessibility standard your funder asks about, and it probably does.
- $20,000 – $31,000
- Sign-in, updates and notifications
- $35,000 – $54,000
- That plus donations and a staff portal
- $39,000 – $59,000
- That plus formal accessibility conformance
Written by
WhatWillMyAppCost
We build the estimator this site runs on, and we design and build custom mobile and web software for a living. Every figure below is the estimator’s own output, except the subscription prices, which are read off each vendor’s pricing page and dated.
You need a number by a deadline, and it has to survive a finance committee. Most of what you can find online stops short of a number, which is no use when the proposal is due Friday.
So here are the figures, what moves them, how to lay them out as budget lines, and the part most nonprofit technology budgets get wrong, which is what happens after the grant ends.
What does a nonprofit app cost?
$20,000 – $31,000 for the simple version: people sign in, see what’s coming up, and get a notification when something changes. $35,000 – $54,000 once you can take donations inside it and staff have a web page to post updates and see who signed up. That second one is what most organizations actually mean.
Add formal accessibility conformance and it’s $39,000 – $59,000. Do not treat that as optional. If you take federal money, or state money, or you serve the public, somebody is going to ask, and retrofitting it later costs several times what building it in costs.
Price your own if your program looks different. Two minutes, and the description’s already there.
How do you put this in a proposal?
As four lines, not one. A single "app development" line invites a reviewer to cut it in half, and a phased budget survives review far better than a lump sum does.
Discovery and design, roughly a fifth of the build, and the piece you can fund first on its own
Build, the bulk of it, worth splitting across two grant years if the funder allows
Accessibility conformance and testing, called out by name because funders look for it
Year one hosting, support and maintenance, which is the line most proposals leave off
Naming accessibility as its own line does two things. It shows the reviewer you knew to think about it, and it protects the money if the rest of the budget gets trimmed.
What happens when the grant runs out?
This is the question that sinks nonprofit software, and it gets asked in year two, not year one. Apple and Google ship new phone software every year whether or not you have funding, and an app nobody has touched in eighteen months starts breaking on devices your people actually own.
- What most proposals budget
- The build. One number, one grant year, and a launch date near the end of it.
- What it actually needs
- The build, plus a smaller recurring amount every year after for hosting, store fees, and the work of keeping it running on new phones. Put it in the proposal. A funder would much rather see it than fund something that stops working in two years.
If you can only fund the build and not the years after it, build something smaller. A modest app that still works in year four does more for the people you serve than an ambitious one that broke in year two.
Should you build anything at all?
Quite possibly not, and it’s worth twenty minutes to check. A lot of what organizations want an app for is already solved by things you can pay a small monthly fee for, and a few are free to nonprofits.
Donations, event sign-ups, email and text updates, and volunteer scheduling all have products behind them. If that’s your whole list, buy them and spend the grant on program. Building is right when the thing you do is the thing no product does, and for social service organizations that’s more often true than people expect.
A mobile app is also not always the answer. If the people you serve are on older phones or tight data plans, a website that works well on a phone reaches more of them and costs less. How the estimate is put together shows what changes when you drop the app stores.
A members app with donations and a staff portal runs $35,000 – $54,000, or $39,000 – $59,000 built to the accessibility standard funders ask about.
Budget it as four lines instead of one, put the years after launch in the proposal, and check whether something off the shelf already does it before you write any of it.
Questions from nonprofits
How much does it cost to build an app for a nonprofit?
$20,000 – $31,000 for sign-in, updates and notifications. $35,000 – $54,000 with donations and a staff portal, which is what most organizations mean. $39,000 – $59,000 built to formal accessibility conformance.
Do nonprofits get a discount on app development?
Some studios reduce rates for nonprofits and some do a fixed amount of pro bono work a year, so ask. The larger saving is usually scope, not rate. Cutting one kind of user or one feature moves the number more than a discount will, and it’s in your control.
Does it have to be accessible?
If you take federal or state funding, or you serve the general public, assume yes and budget for it. It’s roughly the difference between $35,000 – $54,000 and $39,000 – $59,000 when it’s designed in from the start. Retrofitting it later costs several times that, so this is the wrong place to save.
How do we budget for the years after the grant?
Put a recurring annual line in the proposal for hosting, app store fees and maintenance. Funders are used to seeing it and would rather fund something sustainable. Leaving it out is how organizations end up with an app that stops working two years in and no money to fix it.
Can we do this in phases across two grants?
Yes, and it usually reviews better. Design and a clickable prototype in year one, the build in year two. The prototype also gives you something to show the second funder, which is worth more than a description of a plan.
Should we build an app or a website?
A website unless you need notifications, the camera, or it has to work without a connection. If the people you serve are on older phones or limited data, a website reaches more of them, costs less, and needs nobody to download anything.
Who owns the app when it is finished?
You should, and it should be written down before work starts. Make sure the contract covers the code, the designs, the app store listings and the cloud accounts by name. A transfer of "the application" that leaves the developer account in somebody else’s name has not transferred very much.