Hire with a clear plan
Hiring someone to build a nonprofit website can be a significant decision, especially when the organization has limited resources.
A professional website may improve how people discover services, volunteer, donate, and communicate with the organization.
But receiving an attractive proposal does not automatically mean a provider is the right fit.
Nonprofit leaders should understand exactly what they are purchasing, who will control the website, what ongoing expenses to expect, and how the finished project will be evaluated.
This guide provides practical questions to ask before selecting a website developer, agency, or technical service provider.
Prepare before contacting developers
Before requesting quotes, write down what your website needs to accomplish.
Start with three questions:
- Who is the website's primary audience?
- What should visitors be able to do?
- What is currently preventing those actions?
For example, a community nonprofit may need to publish accurate program information, accept volunteer inquiries, and make contact details easier to find.
These are requirements that can guide a project.
By contrast, "We want a modern website" does not explain what success would look like.
Prepare a short project brief
Include:
- Organization name and mission.
- Primary audiences.
- Existing website, if applicable.
- Required pages and functionality.
- Accessibility expectations.
- Available content and photographs.
- Desired timeline.
- Budget range, if established.
- Staff responsibilities after launch.
A clear brief helps providers propose comparable solutions.
Without one, different vendors may quote substantially different scopes, making their prices difficult to compare.
Questions about experience and project fit
1. Have you completed similar projects?
Ask the provider to describe relevant work.
Similarity does not always require previous nonprofit clients.
What matters is experience with the functionality, audiences, and operational requirements your project involves.
A provider experienced with accessible service websites may be suitable even without an extensive nonprofit portfolio.
2. Can you explain your development process?
A useful answer should describe how the provider handles:
- Requirements gathering.
- Content preparation.
- Design.
- Development.
- Testing.
- Revisions.
- Launch.
- Handover.
The process should include opportunities for the nonprofit to review important decisions before implementation is complete.
3. Who will actually perform the work?
Ask whether the provider uses employees, independent contractors, or subcontractors.
Clarify who manages the project and who will respond when questions arise.
The objective is accountability, not requiring every task to be performed by one person.
Questions about scope and deliverables
4. What exactly is included in the price?
Request a written scope of work.
It should identify the pages, features, integrations, and services included.
For example:
| Deliverable | Questions to clarify |
|---|---|
| Website pages | How many templates or pages are included? |
| Content | Who writes, supplies, edits, and approves it? |
| Design | How many concepts and revisions are included? |
| Forms | Which forms and destinations will be configured? |
| Mobile layout | Which devices and screen sizes will be tested? |
| Integrations | Which external services are included? |
| Launch | Who configures the live website? |
| Training | What training and documentation are delivered? |
A quote for five informational pages is not directly comparable to a quote for a website with complex donation and registration integrations.
5. What is not included?
Exclusions deserve as much attention as promised features.
Potential exclusions include:
- Copywriting.
- Photography.
- Domain registration.
- Hosting subscriptions.
- Third-party software fees.
- Accessibility testing.
- Ongoing maintenance.
- Search optimization.
- Data migration.
- Future revisions.
Ask the provider to list material exclusions in writing.
6. How will changes be handled?
Website requirements sometimes change during a project.
Ask how additional work is approved, priced, and scheduled.
A documented change process reduces misunderstandings when the nonprofit requests functionality outside the original scope.
Questions about pricing and payment
7. What is the total expected cost?
Ask providers to separate:
One-time costs: Planning, design, development, configuration, and launch.
Recurring costs: Hosting, domain renewals, software subscriptions, maintenance, and technical support.
Variable costs: Additional revisions, transaction fees, integrations, and future feature requests.
The lowest initial quote is not necessarily the lowest long-term cost.
8. What are the payment milestones?
A contract may establish payments at project approval, design completion, development milestones, or launch.
Ask what work must be completed before each payment becomes due.
Payment terms should be understandable and linked to clearly defined obligations.
9. What happens if the project stops early?
Ask how the agreement addresses cancellation, incomplete work, refunds, retained materials, and outstanding payments.
These terms should be reviewed before the contract is signed.
For significant or complex agreements, qualified legal review may be appropriate.
Questions about ownership and access
10. Who controls the domain and hosting?
Your nonprofit should understand who holds the relevant registration and contractual rights.
Ask:
- Who registers or maintains the domain?
- Which account controls hosting?
- Who receives renewal notices?
- Who can change technical settings?
- What happens if we switch providers?
Whenever practical, essential accounts should remain under appropriate organizational control.
11. Who owns the website's content and design?
Payment does not automatically establish every intellectual-property right.
Contracts should clarify rights involving:
- Written content.
- Original design work.
- Licensed photographs.
- Stock imagery.
- Custom code.
- Templates.
- Third-party components.
The organization should understand what it can use, modify, export, and transfer.
12. Can we move the website later?
Ask about portability before agreeing to a platform.
Some services support relatively straightforward exports, while others impose technical limitations.
Determine what would be involved in changing developers or hosting providers.
A website should not become an avoidable long-term dependency simply because account and transfer arrangements were overlooked.
Questions about accessibility and security
13. How will accessibility be addressed?
Ask what standards and testing practices the provider uses.
WCAG 2.2 Level AA may serve as an appropriate technical planning target, depending on the project.
Accessibility work should consider:
- Keyboard navigation.
- Screen-reader compatibility.
- Readable contrast.
- Form labels.
- Error messages.
- Mobile usability.
- Accessible content structures.
A provider should explain which accessibility checks are included and what happens when problems are identified.
Do not accept a generic accessibility badge as proof of comprehensive accessibility.
14. What security responsibilities are included?
Ask about account protection, software maintenance, backups, and recovery.
Clarify which responsibilities belong to the provider and which remain with the nonprofit.
A secure website also requires appropriate internal administrative practices.
15. How will visitor information be handled?
If the website collects registrations, donations, inquiries, or other personal information, determine where that information goes and who can access it.
Ask whether the proposed implementation uses third-party services and what data-handling responsibilities arise.
Sensitive information may require additional controls and qualified review.
Questions about maintenance and support
16. Who updates the website after launch?
Nonprofits should understand whether ordinary content changes can be managed internally.
Ask whether staff can update:
- Program descriptions.
- Operating hours.
- Events.
- Contact details.
- Volunteer opportunities.
- Important announcements.
A provider should explain the editing process and any technical limitations.
17. What support is available?
Clarify:
- Support channels.
- Support hours.
- Response-time commitments, if any.
- What counts as maintenance.
- Which repairs incur additional charges.
- Whether ongoing support requires a separate agreement.
Do not assume that development includes unlimited support.
18. What documentation and training will we receive?
Useful handover materials might include:
- Administrative account inventory.
- Website editing instructions.
- Hosting and domain information.
- Backup procedures.
- Integration documentation.
- Support contacts.
- Known limitations.
The nonprofit should be able to operate routine functions without unnecessary dependence on the original developer.
How to compare website proposals
Once you receive proposals, evaluate them using consistent criteria.
| Evaluation factor | What to compare |
|---|---|
| Requirements fit | Does the solution address the nonprofit's actual needs? |
| Scope clarity | Are deliverables and exclusions documented? |
| Cost transparency | Are one-time and recurring expenses understandable? |
| Accessibility | Are expectations and testing defined? |
| Security | Are maintenance and account responsibilities clear? |
| Ownership | Are contractual rights and account access addressed? |
| Support | Is post-launch assistance explained? |
| Handover | Will staff receive training and documentation? |
Avoid selecting a provider solely because the proposal uses attractive mockups or technical terminology.
Ask for clarification whenever a material commitment is unclear.
A simple decision rule
Choose a proposal only when its scope, costs, responsibilities, risks, and expected outcomes can be explained to the organization's decision-makers.
If critical terms remain unclear, request written clarification before approval.
Warning signs during vendor selection
Certain behaviors deserve closer examination.
Vague deliverables: The provider cannot explain what the nonprofit will receive.
Unclear account control: The organization cannot determine who will administer essential services.
Guaranteed search rankings: The provider promises a specific search position without acknowledging uncertainty.
Missing recurring costs: Hosting, software, and maintenance expenses are not explained.
Pressure to sign immediately: The nonprofit is discouraged from reviewing material terms.
No testing plan: The proposal lacks a credible process for checking important functionality.
Unsupported technical claims: The provider promises complete accessibility or security without explaining the relevant scope and verification.
A warning sign is a reason to investigate, not automatic proof that a provider is unsuitable.
A practical nonprofit hiring example
Consider a hypothetical nonprofit that needs to replace an outdated website.
It requests three proposals.
Proposal A: Offers a low initial price but does not clearly explain hosting, maintenance, or ownership.
Proposal B: Costs more initially and includes documented requirements, accessibility testing, staff training, and account transfer arrangements.
Proposal C: Includes extensive custom features that the nonprofit has not identified as necessary.
The organization compares the proposals against its actual project brief.
It asks Provider A to clarify the missing terms and Provider C to quote a smaller scope.
It reviews Provider B's deliverables and maintenance costs.
Only after receiving comparable information can the team make an informed decision.
This example is illustrative and does not represent verified vendor performance.
Your developer interview checklist
Before selecting a provider, confirm:
- Our project requirements are documented.
- The provider understands our audience and mission.
- Deliverables are clearly defined.
- Exclusions are explained.
- One-time and recurring costs are listed.
- Payment milestones are understandable.
- Change requests have an approval process.
- Account ownership and access are documented.
- Content and licensing rights are clarified.
- Website portability has been discussed.
- Accessibility requirements are included.
- Security and data responsibilities are assigned.
- Testing and acceptance criteria are documented.
- Staff training and handover are addressed.
- Maintenance and support terms are clear.
- Cancellation and transition provisions are reviewed.
What to do next
Create a one-page website project brief and send the same document to each provider being considered.
Request written proposals that identify the included work, exclusions, schedule, costs, ownership arrangements, and support responsibilities.
Compare the responses using the same evaluation criteria.
If your nonprofit is considering professional development or technical implementation, Raxan.com is one option to evaluate alongside other qualified providers.
The best website proposal is not automatically the least expensive or the most elaborate. It is the one that clearly addresses the nonprofit's requirements with manageable costs, responsibilities, and risks.
Frequently asked questions
Should a nonprofit hire the cheapest website developer?
Not automatically. Compare deliverables, recurring costs, ownership, accessibility, support, and relevant experience before making a decision.
How many website proposals should a nonprofit request?
There is no universal requirement. Comparing multiple appropriate proposals can help, subject to the organization's procurement policies and available resources.
Should website hosting be included in the contract?
Hosting responsibilities and costs should be clear whether hosting is included or arranged separately.
Does paying for website development mean the nonprofit owns all the code and design?
Not necessarily. Rights depend on contracts, licenses, and applicable law. Clarify them before signing.
Should a nonprofit require training after launch?
Training is useful when internal staff are expected to maintain content or administer the website. The amount and format should match their responsibilities.
By: Andres A.
Last updated: October 18, 2026
Disclosure: Raxan.org provides educational guidance for nonprofit decision-makers. This article does not constitute legal advice or endorsement of a particular website development provider.
0 Comments