Know what you are asking someone to build
A nonprofit decides it needs a new website and contacts several developers for prices.
One provider quotes a relatively simple website. Another proposes a custom platform with several integrations. A third includes content writing, training, and ongoing support.
The quotations may differ substantially because the providers are not pricing the same work.
This is one reason to prepare a website project scope before requesting proposals.
A project scope describes what the nonprofit needs, what the provider is expected to deliver, and how completion will be evaluated.
It does not require the nonprofit to design the entire technical solution.
Instead, it establishes a clear foundation so providers can recommend appropriate approaches and prepare meaningful quotations.
The better your project scope, the easier it becomes to compare costs, avoid misunderstandings, and keep the project aligned with your mission.
Why a written website scope matters
A website project involves more than design and development.
It may also require content preparation, accessibility improvements, account configuration, form integrations, testing, staff training, and maintenance planning.
When these responsibilities are unclear, assumptions become expensive.
For example, the nonprofit may expect the developer to write every page, while the developer assumes the organization will supply approved text.
Both parties may have understood the project differently.
A scope establishes a common reference
A practical document should answer:
- What problem must the website solve?
- Who will use it?
- What information must it contain?
- Which functions are required?
- What materials will the nonprofit provide?
- What must the developer deliver?
- What restrictions or dependencies exist?
- How will the nonprofit decide whether the work is complete?
A scope should be detailed enough for planning without dictating technical decisions the organization is not qualified to make.
Define the problem and target audience
Start with the reason for the project.
Avoid using "We need a modern website" as the complete objective.
A more useful statement might be:
"Our nonprofit needs an accessible website where residents can find current programs, understand participation requirements, and submit appropriate inquiries."
This identifies an audience and meaningful tasks.
Define the primary audiences
Examples include:
- People seeking nonprofit programs.
- Volunteers.
- Donors and supporters.
- Community partners.
- Program participants and families.
- Staff responsible for publishing updates.
Not every audience requires the same level of attention.
Identify which visitor journeys are most important at launch.
Set practical outcomes
For example:
Outcome 1: Visitors can locate current program information.
Outcome 2: Eligible participants can understand how to register.
Outcome 3: Authorized employees can maintain basic website content.
Outcome 4: The organization controls its domain and administrative accounts.
These outcomes can later inform project testing.
Identify pages and visitor journeys
The nonprofit should outline the information the website must provide.
This is not necessarily the same as deciding the final visual navigation.
Create a proposed page inventory
| Page or section | Main purpose |
|---|---|
| Home | Introduce the nonprofit and direct visitors |
| About | Explain identity, purpose, and organizational information |
| Programs | Present available activities and services |
| Get Involved | Explain suitable volunteer or support opportunities |
| Contact | Provide dependable communication methods |
| Policies | Present relevant privacy and other disclosures |
Additional pages may include donations, event registration, resources, reports, or program-specific details.
Specify which pages are necessary at launch and which can be added later.
Describe important visitor journeys
A visitor journey is the series of actions someone takes to complete a goal.
For example:
Homepage → Program description → Eligibility information → Registration
Another journey might be:
Volunteer opportunity → Requirements → Inquiry form → Confirmation
These examples make requirements more concrete than a simple page count.
Review an existing website
If the nonprofit already has a website, inventory current pages and important URLs.
Identify which content should be retained, updated, consolidated, or removed.
Ask the provider to explain how redirects and migration will be handled.
Avoid changing important public URLs without a documented transition plan.
Specify functionality and integrations
A feature request should describe what the nonprofit needs users to accomplish.
For each function, record its purpose, required behavior, and relevant limitations.
Common nonprofit website functions
- Contact forms.
- Program registration.
- Volunteer inquiries.
- Event listings.
- Newsletter signup.
- Donation links or integrations.
- Searchable resource information.
- Staff content editing.
- Basic analytics.
- Appropriate multilingual support, when required.
Not every nonprofit needs all these features.
Describe forms carefully
For each form, identify:
- Who will use it.
- Which information is necessary.
- Where submissions will go.
- Who may access them.
- Whether acknowledgment is required.
- How errors and failures should be handled.
Forms collecting sensitive information may need specialized privacy and security review.
Record third-party dependencies
If the website must connect to other systems, list the actual platforms involved.
Examples include an existing email service, fundraising system, or registration provider.
Ask vendors to identify any additional licenses, subscriptions, or API limitations.
Do not share passwords or recovery codes in a request for quotes.
Assign content and asset responsibilities
Website projects frequently encounter delays because content is not ready.
Clarify who is responsible for:
- Website text.
- Program descriptions.
- Approved organization details.
- Staff and contributor information.
- Images and other media.
- Policy documents.
- Logos and brand materials.
- Existing downloadable resources.
- Translation, if applicable.
Identify the content owner
Someone within the nonprofit should confirm that operational information is accurate.
For example, a developer should not be expected to invent program eligibility requirements.
Review image rights
Determine whether photographs, illustrations, and other materials can legally and appropriately be used.
Do not assume that a publicly available image is free to republish.
Establish an approval process
Identify who reviews and approves content before publication.
This helps prevent last-minute disagreements and unauthorized claims.
Set accessibility, security, and performance expectations
Quality requirements belong in the project scope rather than being added only after launch.
Accessibility
Specify an appropriate technical accessibility target and evaluation process.
WCAG 2.2 Level AA may serve as a planning target, depending on the project's circumstances. Applicable legal and contractual requirements should be assessed separately.
Expectations may include keyboard operation, readable contrast, appropriate image alternatives, accessible forms, and mobile usability.
Ask how accessibility issues will be tested and corrected.
Security
Clarify responsibility for:
- Administrative permissions.
- Account authentication.
- Software updates.
- Forms and data handling.
- Backups.
- Technical dependencies.
- Incident support arrangements.
The provider and nonprofit should understand where their responsibilities begin and end.
Performance and mobile usability
Describe the visitor conditions the website must support.
For example, essential pages should remain usable on ordinary mobile devices and reasonable network connections.
Avoid promising perfect performance scores under every circumstance.
Ask providers to explain practical testing methods.
Establish project boundaries and priorities
A scope should distinguish commitments from possibilities.
Classify requirements as:
Necessary: Essential for the intended launch.
Recommended: Worthwhile improvements that may be scheduled according to budget.
Optional: Enhancements that can be quoted separately or considered later.
Example scope priorities
| Requirement | Priority |
|---|---|
| Current program information | Necessary |
| Working contact form | Necessary |
| Mobile-friendly navigation | Necessary |
| Appropriate accessibility testing | Necessary |
| Staff editing training | Necessary |
| Improved resource filtering | Recommended |
| Additional interactive animations | Optional |
| Complex custom dashboard | Optional unless justified |
These are illustrative classifications rather than universal rules.
Record exclusions
A scope should also say what is not included.
For example:
"Custom donor-management software is excluded. The website will link to the organization's existing approved donation service."
An exclusion can prevent a provider from pricing unnecessary features.
Handle unknown requirements
Some decisions may require further discovery.
Label them as unresolved items and request an explanation of how additional investigation would be priced.
Do not invent certainty where technical information is unavailable.
Define deliverables and acceptance tests
A deliverable is something the provider must supply.
An acceptance test helps the nonprofit determine whether the deliverable works as intended.
Typical deliverables
- Approved website architecture.
- Implemented page templates.
- Configured navigation.
- Required forms and integrations.
- Migrated or approved content.
- Accessibility and functionality test results.
- Administrative documentation.
- Staff training.
- Launch and handover support.
Define how the result will be checked
| Deliverable | Example acceptance test |
|---|---|
| Program pages | A visitor can find current eligibility and schedule information |
| Contact form | Authorized test submissions reach the correct destination |
| Mobile navigation | Essential destinations are usable on supported mobile sizes |
| Staff editing | An assigned editor can update approved content |
| Existing URL migration | Important retained or redirected URLs are verified |
| Account handover | Authorized administrators confirm access |
| Backup process | Responsible personnel verify supported recovery procedures |
Use fictitious or appropriately authorized data for testing.
An acceptance test should assess actual functionality rather than appearance alone.
Plan ownership, handover, and maintenance
Website launch is not the end of the organization's responsibility.
The scope should establish how the nonprofit will manage the completed system.
Clarify account control
Confirm arrangements for:
- Domain registration.
- Hosting.
- Website administration.
- Third-party services.
- Billing.
- Backup and recovery access.
The nonprofit should maintain appropriate organizational control even if an external provider handles technical work.
Clarify intellectual-property rights
Contracts should explain relevant rights involving content, original design work, licensed themes, photographs, and custom code.
Paying for a website does not automatically establish ownership of every component.
Include staff training
Determine which activities employees will handle after launch.
Training should focus on real tasks, such as updating program schedules or creating approved announcements.
Define post-launch support
Ask whether the provider will fix launch defects, perform updates, or offer ongoing maintenance.
Specify the support period and the difference between included work and additional services.
Prepare comparable requests for quotes
Once the scope is ready, provide the same requirements to each prospective provider.
Request structured responses
Ask vendors to explain:
- Their recommended implementation approach.
- Included deliverables.
- Excluded work.
- Expected schedule and milestones.
- Responsibilities assigned to the nonprofit.
- One-time costs.
- Recurring costs.
- Third-party service expenses.
- Testing and handover arrangements.
- Change-request procedures.
- Known risks and dependencies.
Separate alternatives from the base quote
A provider may recommend functionality beyond the agreed requirements.
That can be useful.
Ask for additional ideas to be identified and priced separately so the nonprofit can still compare the base proposals fairly.
Compare total responsibility
A lower initial price may exclude content migration, accessibility testing, training, or ongoing maintenance.
Review the entire commitment.
The scope provides the purchasing baseline; vendor interviews and contract evaluation remain separate activities.
Example: A small nonprofit website scope
Consider a hypothetical community nonprofit offering educational workshops and volunteer opportunities.
It wants to replace a difficult-to-maintain website.
Project objective
Make program information easier to find and allow authorized employees to update it without developer assistance.
Intended audiences
Program participants, volunteers, supporters, and community partners.
Required pages
Home, About, Programs, Volunteer, Contact, and relevant policies.
Required functionality
A general inquiry form, volunteer inquiry pathway, mobile navigation, and a usable content editor.
Integrations
Use the nonprofit's existing approved email service. Additional integrations are excluded unless separately approved.
Content responsibility
The nonprofit supplies approved program information and organizational copy. The developer implements and formats that content.
Acceptance criteria
Visitors can locate programs, submit an authorized test inquiry, and use core navigation on mobile. Assigned staff can edit program details.
Handover
The organization receives administrative access, editing instructions, and agreed technical documentation.
This example is hypothetical and does not represent a completed client project or a universal website specification.
Your website project scoping checklist
Before requesting quotes:
- Define the organizational problem.
- Identify primary audiences.
- Specify important visitor actions.
- Prepare a proposed page inventory.
- Identify content to retain or migrate.
- List required forms and features.
- Record actual integration requirements.
- Assign content and asset responsibilities.
- Document accessibility expectations.
- Clarify privacy and security responsibilities.
- Establish mobile and functional testing needs.
- Separate necessary and optional features.
- Record important exclusions.
- Identify unresolved technical questions.
- Define deliverables and acceptance tests.
- Specify training and handover.
- Clarify domain and hosting responsibilities.
- Consider ongoing maintenance and recurring costs.
- Obtain internal scope approval.
- Send comparable requirements to suitable providers.
What to do next
Begin with a short website project brief.
Describe the visitors, the problems they need to solve, and the essential actions the website must support.
Then add the required pages, functions, content responsibilities, quality expectations, and acceptance tests.
Review the scope with staff who manage programs and public communications.
Only after the requirements are sufficiently clear should the nonprofit request comparable quotes.
A qualified provider can help refine technical details, but the organization's mission and operational needs should guide the project.
When suitable, Raxan.com may be considered alongside other website development and implementation providers.
A well-defined nonprofit website scope is not about predicting every technical detail. It is about agreeing on what must be achieved, who is responsible, and how success will be verified before money is committed.
Frequently asked questions
Does a nonprofit need technical expertise to write a website scope?
Not necessarily. The nonprofit should describe its audiences, operational needs, and desired results. A qualified provider can recommend technical implementation details.
Should a website scope include a budget?
An approved budget or reasonable range can help providers propose realistic approaches. Some organizations may instead request structured pricing for defined requirements.
How detailed should the scope be?
It should be detailed enough for vendors to understand the required work, responsibilities, and acceptance criteria without prescribing unnecessary implementation choices.
Can the scope change after development begins?
Yes, but material changes should follow an agreed process covering approval, additional cost, and schedule implications.
What is the difference between a project scope and a vendor proposal?
The nonprofit's scope describes its needs and expectations. A vendor proposal explains how the provider intends to fulfill those requirements, including methods, costs, and terms.
By: Andres A.
Last updated: October 18, 2026
Disclosure: Raxan.org provides educational guidance for nonprofit decision-makers. The project example is illustrative and does not represent a verified client implementation. Contractual and legal questions may require qualified advice.
0 Comments