How to Choose a Nonprofit Website Design Agency

Choosing a nonprofit website design agency is not only about finding attractive portfolio work. The right decision also depends on who owns the website, who controls the domain and hosting, what is included in the proposal, how accessibility is handled, and what happens if your organization leaves the provider.

For nonprofit leaders who are buying digital services for the first time, these details can be difficult to evaluate. This guide gives you a practical decision path, from deciding whether you need an agency to writing a brief, comparing proposals, asking 12 key questions, and checking hosting and handover terms.

What does a nonprofit website actually need?

Before comparing agencies, define what your website needs to do. This gives you a practical yardstick for evaluating proposals instead of judging providers only by visual design.

A donation path that works on a phone: Mobile visitors made up 52% of nonprofit website visits among M+R Benchmarks participants in the 2026 edition, based on 2025 data. However, mobile accounted for 43% of donation transactions and 28% of donation revenue among those participants. The figures do not mean mobile is the main source of donations, but they do support giving the mobile donation path deliberate attention.

Pages staff can edit: Your team should know who will update content after launch. A site that requires a developer for every routine content change can create unnecessary dependency.

Accessibility and speed: Ask how accessibility is tested and which standard the agency builds toward. WCAG 2.2 AA can be used as a practical build standard, but automated tools do not catch every accessibility issue. Manual testing should also be part of the conversation.

A way to measure results: Before hiring, decide what you need to understand after launch. That could include website activity, donation activity, or other outcomes that matter to your organization. Ask who owns the data and who can access it.

WebAIM’s 2026 analysis found detectable WCAG failures on 95.9% of the top one million home pages tested, with low-contrast text appearing on 83.9%. The analysis uses automated testing and covers the top one million sites, not nonprofits specifically, so it should be treated as evidence that accessibility needs to be actively tested rather than assumed.

If you would rather have the build handled for you, organization website design and development can be considered.

Should you build it yourself or hire someone?

Not every nonprofit needs an agency. A volunteer, staff member, or template-based site can be enough when the requirements are simple and the organization has someone who can reliably maintain it.

Build yourself may fit when	Hiring a provider may fit when
The site is a small brochure-style website.	The existing site needs a substantial rebuild.
Content changes are limited.	Several teams need to manage content and workflows.
A hosted donation button covers the donation requirement.	The donation path or donor systems need development work.
A capable person can maintain the site.	Accessibility testing requires specialist attention.
The person responsible can document the setup before leaving.	Existing URLs need to be mapped during a rebuild.
The organization can handle routine security and maintenance responsibilities.	Ongoing technical responsibility needs to be clearly assigned.

The biggest issue with volunteer-built websites is not the volunteer themselves. It is key-person risk. If the person who understands the website leaves, the organization can be left without the knowledge or credentials needed to maintain it.

There are also tasks that deserve particular scrutiny before deciding to build everything internally:

• Rebuild protection: Existing URLs need to be mapped to their new destinations, with permanent 301 redirects where appropriate.
• Accessibility testing: Automated tools identify only some accessibility issues, so manual testing matters too.
• Payment and donor systems: Confirm exactly how your chosen payment or donation provider works before making compliance assumptions.
• Ongoing security: Someone must remain responsible for updates, backups, security, and recovery.
• Handover: The organization should know where its domain, hosting, analytics, content, design files, and credentials are held.

The question is not simply whether you can build a website. It is whether your organization can maintain control of it after the person who built it is no longer involved.

For donation paths and donor systems, donation and fundraising platform development covers the giving side of the project.

How do you write the brief before you approach any provider?

A one-page brief makes provider conversations easier because every agency receives the same starting information. It also helps you separate essential requirements from features that can wait.

Include:

• Goals: What should the new or rebuilt website help the organization accomplish?
• Audiences: Who needs to use the website?
• Pages and features: List the pages and functions that are essential.
• Current website: Record important URLs, the current platform, and the donation tool.
• Budget: Give a budget range if possible, or explain whether you prefer phased work.
• Content ownership: Identify who will create and maintain website content.
• Timeline: State any important deadlines or dependencies.
• Decision makers: Identify who will review proposals and approve the project.
• Existing risks: Note known accessibility, donation, hosting, content, or maintenance problems.

Avoid writing the brief around a particular technology unless your organization has a specific reason to require it. The provider should be able to explain how its proposed approach addresses your actual requirements.

If budget is a major concern, ask providers to separate essential work from optional phases rather than relying on a vague nonprofit discount.

You can also explore websites for organisations when writing your brief.

What are the 12 questions to ask before you hire?

Use the same questions with every provider you are seriously considering. The purpose is not to find the answer that sounds most impressive. It is to find an answer that is clear, specific, and documented.

Question	Good answer	Warning answer
1. Which nonprofits have you worked with, and can I speak to one?	They can explain relevant experience and provide an appropriate reference where permitted.	They avoid discussing relevant experience or cannot explain what they actually delivered.
2. Which accessibility standard do you build to, and how do you test it?	They identify a standard such as WCAG 2.2 AA and explain both automated and manual testing.	They describe accessibility as a plugin, checkbox, or automatic result.
3. Who owns the code, content, and domain?	Ownership and access are clearly stated in the agreement.	Ownership is unclear or important assets are described as licensed back to you.
4. What is included, and what is billed extra?	The proposal separates included work, optional work, and ongoing costs.	One large lump sum provides little detail about scope.
5. What happens to the site if we leave?	They explain the offboarding and handover process.	Leaving is treated as an unusual problem or the provider cannot explain the process.
6. Who maintains it after launch, and what does that cover?	Responsibilities, maintenance work, and related costs are documented.	“Maintenance” is mentioned without explaining what it includes.
7. How do you handle a restricted nonprofit budget?	They discuss phasing, scope trade-offs, and priorities.	They offer an unexplained discount without changing scope or priorities.
8. Who actually hosts the site, and under whose account?	You know who holds the hosting account and how your organization retains access.	The provider controls the account without clearly explaining your access or exit options.
9. How are backups and SSL handled, and by whom?	They explain backup frequency, storage, retention, restore testing, and SSL renewal.	Backups are assumed, or nobody can explain how restoration works.
10. What uptime do you commit to, and how is it measured?	They explain the measurement method, exclusions, and any remedy.	A percentage is quoted without explaining what it means.
11. How will you protect our existing URLs and search rankings in a rebuild?	They explain URL mapping and checked 301 redirects before launch.	They treat the rebuild as only a visual redesign.
12. How will we measure results, and who can see the data?	They define measurement responsibilities and data access.	Reporting is promised without explaining what will be measured or who owns the data.

These questions also make proposals easier to compare because they move the conversation beyond screenshots and feature lists.

Who owns the code, content, and domain, and what happens if you leave?

Ownership should be explicit before the project starts. Do not assume that paying for a website automatically means your organization controls every part of it.

Your handover checklist should cover:

• Code: Confirm what happens to the website code and whether the organization receives access.
• Content: Confirm who owns the written content, images, documents, and other materials supplied for the site.
• Design files: Ask whether design files are included in the handover.
• Domain: The domain should be registered in the nonprofit’s name, with the nonprofit holding the login.
• Hosting account: Confirm who holds the account and how access is transferred if you leave.
• Analytics: Confirm who can access website data and reporting.
• Credentials: Establish where important credentials are stored and how they are transferred.
• Maintenance: Document what happens after launch and which responsibilities become additional charges.

Also ask what is included in the project and what is billed separately. If you want to understand the numbers behind nonprofit website projects, see what a nonprofit website typically costs.

A simple scenario illustrates why this matters. Imagine a volunteer leaves six months after launch. If the organization does not control its domain, hosting, analytics, or other credentials, a simple staff change can become a website access problem.

A clear handover reduces that dependency.

What should you ask about nonprofit website hosting?

Hosting is not simply a line on an invoice. Ask who is responsible for the hosting account, backups, security, SSL, and recovery.

Hosting type	What it generally means	What to ask
Shared	Resources are shared with other websites and it generally provides less control.	Who manages the account, backups, security, and access?
Managed	The hosting provider handles responsibilities such as updates, backups, and security.	What exactly is managed, how are backups tested, and what access does the nonprofit retain?
Dedicated	The organization has dedicated resources and this is generally relevant to high-traffic or special compliance needs.	Why is dedicated hosting necessary for your requirements, and who manages it?

Backups deserve specific questions. Ask how frequently backups run, where they are stored, how long they are retained, and whether restores have actually been tested. A backup that cannot be restored when needed does not provide the same practical protection as a tested recovery process.

SSL should also be clear. Free certificates are widely available, so a separate SSL charge should have a specific reason. Ask whether the certificate is included and renewed automatically.

The domain should remain registered in the nonprofit’s name, with the nonprofit holding the login. Hosting can be managed by another party, but that does not mean the provider should automatically control every related account.

What does 99.9% uptime actually mean?

A 99.9% uptime figure allows 0.1% downtime. That is approximately 8.8 hours of downtime in a year, or about 43 minutes in a 30-day month.

When a provider mentions 99.9% uptime, ask:

• How is uptime measured?
• Is planned maintenance excluded?
• What counts as downtime?
• What happens if the stated uptime is missed?

The percentage alone does not tell you how the provider defines or handles downtime.

For nonprofit website hosting, responsibility is more important than a number presented without context.

What are the red flags in nonprofit web proposals?

A proposal can look professional and still leave important questions unanswered. Watch for these warning signs:

No clear scope: If the proposal does not explain what will actually be delivered, ask for an itemized scope before comparing the price.

Guaranteed rankings: Search performance cannot be responsibly reduced to a guaranteed ranking promise. Ask instead how existing URLs, redirects, technical structure, and measurement will be handled.

No rebuild protection: A new design does not automatically protect existing search visibility. Ask how old URLs will be mapped to new ones and how the redirect list will be checked before launch.

Unclear ownership: If the proposal does not clearly identify who owns the domain, content, code, design files, hosting account, and analytics access, resolve that before signing.

Accessibility as an add-on: Accessibility should be discussed as part of how the site is built and tested. Automated testing alone is not enough.

Unclear recurring fees: Ask which costs continue after launch and which services are optional.

No exit explanation: A provider should be able to explain what happens when the relationship ends, including the handover of relevant assets and credentials.

One-size-fits-all technology: A provider should explain technology in relation to your requirements rather than simply declaring one platform to be the best option.

Why Choose Qrolic

Qrolic Technologies can be evaluated using the same ownership, scope, hosting, accessibility, donation, and handover questions outlined in this guide. If you want to discuss your nonprofit website requirements, Contact Qrolic and use your brief as the starting point.

Our Web Services for Nonprofit Organisations

• Organisation Website Design and Development: If your nonprofit needs a new site or a rebuild, website design and development for organisations is the supplied service relevant to the website build itself. It aligns with the brief’s focus on staff-editable pages, accessibility, speed, and measurement without adding unverified platform or feature claims.
• Donation and Fundraising Platform Development: If the main requirement is improving the donation path or developing fundraising functionality, donation and fundraising platform development is the supplied service relevant to that need. It connects with the article’s focus on making the giving experience work for visitors, including people using mobile devices, without assuming a particular payment provider or integration.

Conclusion

Choosing a nonprofit website design agency should start with your organization’s needs, not with a portfolio alone. Decide whether you need an agency, write a clear brief, compare providers using the 12 questions, and examine ownership, hosting, accessibility, recurring costs, handover, and rebuild protection before signing. A good proposal should make these responsibilities clear enough for a non-technical nonprofit team to understand and evaluate.

Turn Your Brief Into a Clear Scope

A clear project brief gives you a practical starting point for discussing priorities, scope, and what your organization actually needs.

Review Your Requirements