A useful nonprofit website budget separates three things: the cost to launch, the cost to operate, and the time your own team must contribute. Define a small, usable launch scope, ask providers to price the same deliverables, and make accessibility evaluation and staff handoff explicit parts of the work.
There is no single price that fits a neighborhood volunteer group, a regional service organization, and a nonprofit running a member portal. Page count alone will not explain the difference. Content condition, forms, integrations, publishing needs, and the amount of existing material to migrate all affect what you are asking someone to deliver.
1. Start with three visitor tasks
Before requesting quotes, write down the most important things people should be able to do. For a small nonprofit, those might be finding eligibility information, volunteering, and making a donation. For another organization, event details and a reliable contact path may come first.
Describe a successful outcome for each task. “A visitor can find the program location and hours on a phone” is clearer than “make the website modern.” Identify who supplies the information, who approves it, and which outside service the visitor encounters along the way.
This is the purpose of website strategy and information architecture: turn organizational goals into a manageable structure. A short agreed scope gives providers something concrete to estimate and gives your team a way to evaluate the result.
2. Budget for the complete delivery
Ask for a proposal that explains the work behind the finished pages. These are useful budget lines even when a provider bundles several into one fee:
- Discovery and structure: audience needs, content inventory, navigation, requirements, and a delivery plan.
- Content preparation: writing, editing, image permissions, alternative text, and decisions about outdated documents.
- Design and development: reusable page templates, responsive behavior, forms, and the publishing setup.
- Migration and integrations: moving retained content, mapping old URLs, setting redirects, and connecting external tools.
- Evaluation and corrections: functional checks, accessibility review, recorded findings, fixes, and retesting.
- Launch and handoff: deployment, account access, documentation, staff training, and a defined stabilization period.
If a quote leaves one out, ask who will do it. A low development fee can still leave a substantial amount of writing, document cleanup, or manual data entry for your staff. Agree on those responsibilities before comparing totals.
3. Make accessibility part of the scope
Include accessibility in design, content, implementation, and review. Specify the technical standard and evaluation scope in the proposal, including which templates, forms, documents, and third-party journeys will be assessed. Ask how findings will be recorded, corrected, and checked again.
W3C’s guidance on evaluating accessibility recommends checking during development and explains that automated tools need human evaluation alongside them. Budget for both, with representative tasks such as completing a form using a keyboard or reading a page while zoomed in.
A scan is useful evidence, but its score is not a legal certification. Tanglao’s website development and accessibility work emphasize semantic structure, practical testing, remediation, and documented limits. New content and external services also need continued attention after launch.
4. Separate launch costs from ongoing costs
Ask for a first-year view and a normal renewal-year view. Hosting may be only one line: include domain renewal, paid platform or plugin subscriptions, monitoring, backups, updates, periodic testing, and support. If donation or email services charge separately, record those terms using the provider’s current pricing.
Include staff effort too. Someone must approve content, learn the editor, update program details, and respond to inquiries. Assign a named role and estimated hours, even if that work will be done by volunteers.
For cloud architecture and hosting, ask whose account holds the system, who receives renewal notices, and who can restore it. Client-owned accounts and a documented recovery procedure make future operations easier to plan. Ask what a backup includes and how a restoration will be demonstrated.
5. Use a scope worksheet before requesting prices
Copy this worksheet into your planning document. Fill it in with each provider so that assumptions and exclusions are visible. The entries below describe a hypothetical small nonprofit, not a Tanglao quote.
- Launch scope
- Program information, about, contact, volunteering, and a link to an existing donation service. Confirm templates and forms separately from page count.
- Content and migration
- Staff draft and approve the copy. Provider inventories old URLs, migrates agreed content, and tests redirects. List documents needing separate remediation.
- Verification
- Agree on accessibility evaluation scope, mobile and functional checks, corrections, retests, and the evidence delivered at handoff.
- Ownership and training
- Name account owners, staff editors, documentation, training sessions, and the person responsible for recovery.
- Money and time
- Record the initial fee, recurring charges and renewal dates, internal hours, optional items, and a reserve for agreed changes.
A simple planning equation is: first-year commitment = delivery fee + first-year operating charges + internal effort + change reserve. Track staff hours separately if you cannot reasonably assign a monetary cost. Set the reserve after discussing uncertainty; old content and undocumented integrations deserve particular attention.
6. Phase features while keeping launch usable
Imagine a volunteer-led organization with an outdated site and limited editing capacity. Its first release could focus on accurate service information, a working contact form, an existing donation link, responsive templates, and training for two editors. Accessibility evaluation and corrections belong within that release.
A later phase might add a searchable archive or connect volunteer intake to an internal system, once the team understands the workflow. Record these as separate options with their own assumptions and estimates. This lets you reduce feature scope without quietly removing the work needed to verify and maintain the initial site.
Before approving the proposal
- Can you identify the essential visitor tasks and agreed deliverables?
- Are content, migration, integrations, testing, and retesting assigned?
- Are operating costs, renewal terms, and internal hours visible?
- Will your organization control its accounts and receive practical documentation?
- Does the proposal explain approval milestones, change requests, training, and post-launch support?
W3C’s accessibility planning resources offer further guidance on responsibilities and ongoing stewardship. Use them alongside your organization’s publishing and operational needs when defining the project.