Insights · 7 min read
Choosing an app developer for a nonprofit: a checklist
By Austin Hunter ·
Nonprofits hire developers under unusual constraints: grant timelines, board approvals, people with every level of digital access, and very little room for a project that goes sideways. We read a lot of nonprofit RFPs and build mission-driven software ourselves. This is the checklist we'd want a nonprofit to use on us.
1. You own everything
- The code lives in a repository your organization owns.
- The app is published under your own App Store and Google Play accounts, not the developer's.
- Domains, hosting and third-party services are in your accounts, paid at cost.
- Ask: "If we part ways, what do we have to do to keep running?" The right answer is "nothing."
2. Accessibility is built in, not bolted on
- Ask which standard they test against (WCAG 2.1 or 2.2 Level AA is typical) and how: automated scans plus manual keyboard and screen-reader testing.
- Avoid "accessibility overlay" widgets as the fix. Problems should be fixed in the code and templates.
- Ask for an example where they made something accessible, and what they changed.
3. The budget matches how you're funded
- Fixed prices per phase you can match to a grant period or board approval.
- Pass-through costs (hosting, texting, store fees) listed separately, so recurring costs are visible to your finance team.
- Year-two costs quoted up front: updates, store requirements, support.
4. Texting and notifications respect consent
- Explicit opt-in per purpose, recorded with time and wording; STOP and HELP handled automatically.
- Carrier registration for text messages (10DLC in the US) planned early, because approval can take weeks.
- A clear rule for when to use push notifications versus SMS.
5. Privacy fits the people you serve
- Collect only what each step needs; let people browse without an account.
- Role-based staff access, audit logs, encryption in transit and at rest.
- Retention and deletion rules agreed before launch.
- If your RFP asks about AI tools, expect a straight answer about how the developer uses them and a commitment not to put your confidential data into third-party tools without approval.
6. The team is honest about its size and experience
- Small teams can be a strength (you work with the person doing the work) but ask about continuity: who covers vacations, and is everything documented and in your accounts?
- Ask for comparable work and references, and check them.
- Be wary of anyone who claims experience in your exact field without examples.
7. Questions to put in your RFP
- Who owns the code, data, accounts and store listings?
- What accessibility standard do you test against, and how?
- What are the one-time, recurring and usage-based costs over three years?
- What happens after launch: response times, updates, release cadence?
- Which subcontractors would touch our data?
- What insurance does the contract require? Say so in the RFP, because it rules some vendors in or out early.
Start with a plan
Our free planning worksheet helps you put the goals, users, must-haves and budget on one page before you talk to developers, and it makes every proposal you receive easier to compare.