What Should a Government or Nonprofit Website Cost? RFP Budget Ranges for 2026

Setting the budget is the hardest line in a public-sector or nonprofit website RFP. Set it too low and you receive proposals from vendors who did not read the scope. Set it too high and you spend money you could have used on programs. Leave it out entirely and you get bids spanning an order of magnitude, most of which were never viable.

What follows is not a market survey, and we are not going to publish invented ranges for other people's work. It is a description of what actually drives the cost of a government or nonprofit website project, so you can build a defensible number from your own inputs — and a note on where our own published pricing sits.

Why published "average cost" figures are close to useless

Search for what a government website costs and you will find confident ranges. Almost none of them state the page count, whether content migration was included, whether accessibility remediation was in scope, or whether the figure covers a template implementation or a bespoke build. Those four variables move the number more than anything else.

A 60-page city site on a well-supported template with no migration and a 900-page county site with twelve integrations, a decade of agendas to preserve and a full accessibility remediation are both "a government website." Treating them as one market is how buyers end up with a budget that cannot buy what the RFP describes.

The variables that actually move the number

Page and document count

The most important input and the one most often unknown. Crawl your current site before you write the budget. Count pages and documents separately: 400 pages and 3,000 PDFs is a very different project from 400 pages and 30. Document remediation is frequently the larger line.

How much content is migrating, and how

Migrating everything is expensive; migrating a curated subset is cheaper and usually better for users. Scripted migration is cheaper per page than manual but only works where the source is structured consistently. Decide the policy before you budget, because "we will figure out migration later" reliably becomes a change order.

Accessibility: build versus remediate

Building accessibly from the start is close to cost-neutral — it is a set of decisions during design and development rather than an add-on. Remediating a live site that was not built that way is a separate, sometimes substantial, piece of work. If you do not know which situation you are in, an accessibility audit will tell you before you commit a number to paper.

Integrations

Each system the site has to talk to — permitting, payments, CRM, agenda management, catalogue, AMS, SIS — carries its own cost, and it depends far more on what the system exposes than on how important it is to you. A well-documented API is a modest line item; a system with no API and a vendor who will not discuss it can dominate the budget.

Translation

Multilingual delivery is a real line, and the cost turns on the choice between machine translation and human translation. That choice matters most on exactly the pages where accuracy is legally significant, which is usually where machine output is least adequate.

Content writing

Frequently assumed by buyers and excluded by vendors. If you need someone to rewrite 200 service pages in plain language, that is a project in its own right, and it should be a separate line item so you can drop or defer it without reopening the procurement.

Governance and training

A site with forty departmental editors needs a permissions model, a component system and real training. A site maintained by one person needs far less. This is one of the few variables where the number of pages barely matters and the number of publishers matters enormously.

Post-launch support

Decide whether ongoing support is inside this budget or a separate line, and for how long. Twelve months of support attached to a capital project is common; so is discovering in month thirteen that nobody budgeted for it.

Build the number from line items, not from a benchmark

Ask for each of the following priced separately, and your budget becomes a sum you can defend to a board or a council rather than a guess: discovery and information architecture; design; development and CMS build; content migration at a stated page count; content writing; accessibility testing and remediation; integrations, itemised per system; translation; training; post-launch support for a stated period; and hosting.

The same structure protects you later. When the number comes back higher than the appropriation, you can defer content writing or reduce migration scope without restarting the procurement.

What we publish, and what we do not

Our pricing page publishes rates for the recurring work — SEO, GEO and AEO packages and website maintenance tiers — because those are standardised enough to quote honestly in public.

Website builds we quote per project, against your line items, after reading the actual scope. That is not evasion: a fixed number published for "a website" would be either high enough to cover the worst case or low enough to require a change order, and both are worse for you than a real quote. Send a scope and you get fixed pricing against it.

Two sanity checks before you publish the number

First, does the budget cover the accessibility work the RFP requires? A solicitation that mandates WCAG 2.2 AA conformance on a 3,000-document estate and budgets for a template implementation is asking vendors to either no-bid or quietly omit the requirement. Most will do the latter.

Second, does it cover migration at the page count you stated? If you have not stated a page count, go back and count. Every other number depends on it.

If you are drafting a solicitation now, the checklists for government website RFPs and nonprofit website RFPs cover the surrounding sections, and how to evaluate proposals covers what to do when the responses arrive. You are also welcome to send us a draft before it goes out — we will tell you where it is ambiguous, with no expectation that we bid.