A municipal website RFP template you can actually use

Before you write a word

An RFP is not a wish list. It is the contract you are going to live inside for the next five to ten years, written before you know who you will be living with. Every ambiguity you leave in it gets resolved later, in a room you are not in, by a vendor's counsel.

That sounds dramatic. It is not. The reason small municipalities end up trapped in websites they cannot change, cannot afford, and cannot leave is almost never that they picked a bad vendor. It is that the RFP never asked the questions whose answers would have told them.

So before the template, three pieces of orientation.

You are procuring a public asset, not a subscription. Your website is where residents apply for permits, read the agenda before the meeting they are going to speak at, and find out whether the water is safe to drink. It is infrastructure. Procure it the way you would procure a piece of infrastructure: with clear title, clear maintenance obligations, and a clear path to a different contractor.

Expect more proposals than you want. One municipality's website redesign RFP drew 33 proposals from vendors across the US and Canada. Thirty-three. If you have not set out in advance how you will score them, you will end up choosing on the strength of the prettiest deck, which is precisely the skill you are not trying to buy. Write your evaluation criteria before the submissions arrive, and see how to score website proposals without drowning in them.

Say less about design and more about terms. Most municipal website RFPs spend four pages on the homepage carousel and one paragraph on the contract. Reverse that. Any competent vendor can make you a nice-looking homepage. Very few will volunteer that leaving them costs money.

The template

What follows is written as RFP language. Bracketed items in [SQUARE BRACKETS] are yours to fill in. The commentary between sections is for you, not for the document — delete it before you publish.

1. Purpose and background

1.1 The [MUNICIPALITY / TOWN / TOWNSHIP / VILLAGE OF _____] ("the Municipality") invites proposals from qualified firms for the design, development, migration, and launch of a new public-facing municipal website, together with the content management system used to maintain it.

1.2 The Municipality has a 2020 decennial Census population of approximately [POPULATION] and is served by [NUMBER] staff, of whom approximately [NUMBER] will require the ability to publish or edit content.

1.3 The Municipality's current website was launched in [YEAR] on [PLATFORM / "a hosted platform" / "an unknown platform"] and consists of approximately [NUMBER] pages and [NUMBER] posted documents. The current site [does / does not] meet WCAG 2.1 Level AA.

1.4 The Municipality's objectives for this project are: (a) a website that meets its obligations under [the Americans with Disabilities Act, Title II / the Accessibility for Ontarians with Disabilities Act / APPLICABLE LAW]; (b) a website that non-technical municipal staff can maintain without vendor assistance for routine content; (c) a predictable, fully disclosed cost of ownership over a minimum five-year horizon; and (d) clear municipal ownership of the resulting website, its source code, its content and its data.

1.5 Nothing in this RFP obligates the Municipality to award a contract, and the Municipality reserves the right to reject any or all proposals.

Clause 1.4 is doing quiet work. It tells every bidder, on page one, what you will be scoring on — and it puts ownership in the objectives rather than burying it in the terms, where it can be negotiated away.

2. Scope of work

2.1 The successful proponent shall provide, at minimum:

(a) Discovery and information architecture, including a review of the Municipality's existing content and a proposed site structure;
(b) Visual design of the public website, responsive across desktop, tablet and mobile;
(c) Development and configuration of a content management system (CMS) permitting municipal staff to create, edit, schedule and publish content without vendor involvement;
(d) Migration of existing content and documents, in a quantity to be confirmed during discovery;
(e) Accessibility conformance testing and remediation prior to launch (see Section 4);
(f) Staff training, together with written or recorded documentation the Municipality may retain and reuse;
(g) Launch, including DNS cutover and redirection of existing URLs to preserve inbound links and search rankings;
(h) A defined post-launch support and warranty period of not less than [90] days;
(i) Delivery of source code, content and data in accordance with Section 6.

2.2 Proponents shall state clearly any element of the above that they propose to exclude, subcontract, or provide only at additional cost.

Item (g) is the one people forget and then feel for two years. If the old URLs are not redirected, every link on every state agency page, every bookmark, and every search result pointing at your zoning bylaw breaks on launch day.

3. Functional requirements

This is the content a municipal website actually has. Not the content a marketing site has. Ask for it explicitly, because "we support custom content types" and "we ship with an agendas and minutes module that your clerk can run" are very different sentences.

3.1 The proposed solution shall support, as first-class, separately structured content types (not merely as free-text pages):

(a) News and announcements, with publication dates, categories and an archive;
(b) Events and a public calendar, with recurring events, locations and downloadable calendar entries;
(c) Agendas and minutes, organised by body and by meeting date, with attached documents, searchable by title and date;
(d) Bylaws, ordinances, resolutions and policies, with number, adoption date, status (in force / amended / repealed) and full text or attached document;
(e) Council and committees, including members, terms, mandates and meeting schedules;
(f) Staff directory, with role, department and contact method;
(g) Departments, each with its own landing page, staff and services;
(h) Services and permits, including application requirements, fees and downloadable or online forms;
(i) Job postings, with closing dates and automatic expiry;
(j) Bid and tender opportunities, with closing dates, addenda and award notices;
(k) Emergency alerts, publishable to the top of every page within [5] minutes by a trained staff member without vendor assistance;
(l) Online forms, with submissions retrievable by staff and exportable;
(m) Frequently asked questions, grouped by topic.

3.2 Site-wide search shall return results across all of the above, including the text of posted documents where technically feasible.

3.3 The CMS shall provide role-based permissions such that a department may edit its own content without the ability to alter other departments' content or site-wide settings.

3.4 Proponents shall state, for each item in 3.1, whether the capability is included in the base proposal, available at additional cost, or not available. Any capability described as "custom" shall be priced.

Clause 3.4 is the whole point of this section. It converts a sales conversation into a table. It is remarkably hard to answer evasively.

Clause 3.1(k) — the alert banner — deserves a moment. Ask how long it takes and who has to be awake. If the honest answer is "you email your account manager," that is not an emergency alert system. It is a ticket queue.

4. Accessibility requirements

4.1 The delivered website shall conform to Web Content Accessibility Guidelines (WCAG) 2.1, Level AA, at minimum, or the most current standard required by applicable law at the time of implementation.

4.2 The Municipality's compliance date under the U.S. Department of Justice rule implementing Title II of the Americans with Disabilities Act is [April 26, 2027 for a 2020 Census population of 50,000 or more / April 26, 2028 for a 2020 Census population under 50,000, or for any special district]. The proposed schedule shall deliver a conformant site in advance of that date.

4.3 The proponent shall submit, with its proposal, a completed Accessibility Conformance Report (ACR), based on the Voluntary Product Accessibility Template (VPAT), for the proposed content management system and front-end templates. Proposals that do not include a VPAT/ACR may be deemed non-responsive.

4.4 The proponent shall describe its testing methodology, including the extent to which testing is automated and the extent to which it includes manual testing and assistive-technology testing. Reliance on automated scanning alone is not acceptable.

4.5 The CMS shall assist municipal staff in producing accessible content — for example by requiring alternative text on images, enforcing correct heading structure, and warning on insufficient colour contrast.

4.6 The proponent shall state whether accessibility conformance is maintained as part of ongoing support, or whether remediation of future issues is billable, and at what rate.

4.7 The proponent shall state whether any part of its accessibility approach relies on a client-side "accessibility overlay" or widget. The Municipality does not consider an overlay to constitute conformance.

Clause 4.3 is the load-bearing one. Every vendor will tell you they are accessible. A VPAT is a structured document in which they tell you, requirement by requirement, where they are not — and it is signed. Asking for one costs you nothing and separates the field immediately.

Get your deadline right before you paste 4.2, because it moved. The dates above are the current ones as of April 2026; a great deal of what is still online says April 2026, and it is wrong. We keep a maintained explainer at where the ADA Title II web rule actually stands, and our own approach is on the accessibility page.

5. Technical requirements

5.1 Hosting. The proponent shall state where the website and its data will be hosted, whether hosting is included in the proposed price, and for how long. The proponent shall state the uptime commitment offered, if any, and the remedy for failing it.

5.2 Data residency. All Municipality content and data shall be stored [within the United States / within Canada / within the Province of _____ / SPECIFY]. The proponent shall state whether any data, including backups, logs, or analytics, is stored or processed outside that region, and by which subprocessors.

5.3 Security. The proponent shall describe: encryption in transit and at rest; authentication for CMS users, including support for multi-factor authentication; its patching cadence; its breach-notification commitment and timeline; and any independent security assessment it has undergone.

5.4 Backups. The proponent shall state backup frequency, retention period, and the tested time to restore. The Municipality shall be entitled to obtain a copy of a backup on request.

5.5 Browser and device support. The site shall function on current versions of Chrome, Firefox, Safari and Edge, and on mobile devices at widths from 320 pixels upward.

5.6 Performance. The proponent shall state target page-load performance and shall demonstrate it on a reference site of comparable scope. Pages shall remain usable on a low-bandwidth connection.

5.7 Integrations. The proponent shall state the cost and method of integrating with [PAYMENT PROCESSOR / GIS / AGENDA MANAGEMENT / UTILITY BILLING / OTHER], and whether such integrations are included.

5.8 Reference sites. The proponent shall provide the URLs of at least three (3) live municipal websites it has delivered, with the name and contact information of a municipal reference for each.

On 5.2: data residency is not paranoia, it is often policy — and in Canada it is sometimes law. Ask the question in writing and keep the answer.

On 5.8: call the references. Ask them one question — "what does it cost you when you want something changed?"

6. Ownership, data and exit terms

This is the section most municipal RFPs do not have. It is also, by a wide margin, the one that will determine what this decision costs you in year six. If you copy nothing else from this page, copy this.

6.1 Ownership of source code. The proponent shall state, unambiguously, who owns the source code of the delivered website at project completion. If the Municipality does not own it outright, the proponent shall state the licence under which the Municipality uses it, and what happens to that licence if the agreement ends.

6.2 Delivery of source code. The proponent shall state whether the complete source code of the delivered site — including templates, configuration, and any custom development — will be delivered to a repository controlled by the Municipality, at project completion, at no additional charge.

6.3 Ownership of content and data. All content, documents, images, form submissions and data entered into the system by the Municipality or its residents shall remain the sole property of the Municipality at all times.

6.4 Export. The proponent shall provide, on request, at any time, at no charge, a complete export of (a) the Municipality's content and data in a non-proprietary, documented format (for example a standard database dump, or structured files such as CSV, JSON, XML or Markdown, with all uploaded documents and images) and (b) the source code described in 6.2. The proponent shall state the maximum time within which such an export will be delivered.

6.5 No exit fee. The proponent shall confirm that no fee, penalty, or charge of any kind — including any "data extraction," "migration," "transition," or "de-conversion" fee — is payable by the Municipality in order to terminate the agreement or to obtain the materials described in 6.4.

6.6 Migration path. The proponent shall describe, in writing, the specific steps by which the Municipality could move the delivered website to a different vendor or to self-hosting, and shall name the technologies involved. A statement that the platform is "proprietary" or that migration is "not supported" shall be disclosed as such.

6.7 Continuity on non-renewal. The proponent shall state what happens to the Municipality's live website if the Municipality declines to renew any optional annual service: specifically, whether the website continues to operate, and for how long.

6.8 Escrow. Where the proponent retains ownership of the source code, the proponent shall state whether source code escrow is offered, at what cost, and the conditions under which it releases.

6.9 Answers to 6.1 through 6.8 shall be incorporated into the resulting agreement.

Read 6.9 again. Without it, the rest of the section is a nice conversation during the sales cycle and nothing at all afterwards. The answers have to end up in the contract.

7. Cost proposal

Do not ask what it costs. Ask what it costs for five years, and make them fill in a table you designed. A vendor who is cheap in year one and 5% more expensive every year thereafter is not cheap; they are just presenting well.

7.1 Proponents shall complete the following table in full. Any cell left blank, marked "TBD," or marked "varies" shall be treated as unquoted and may render the proposal non-responsive.

7.2 The proponent shall state, as a number, any annual increase, escalator, uplift or cost-of-living adjustment applied to any recurring fee at renewal. A statement that fees are "subject to change" or "reviewed annually" is not a number and shall be treated as unquoted.

7.3 The proponent shall state the length of the initial term and of each renewal term, the notice period required to decline renewal, and whether renewal is automatic.

7.4 The proponent shall list every fee not captured above that the Municipality could foreseeably incur in the first five years.

7.5 Evaluation of cost shall be on the basis of the five-year total, not year one.

Clause 7.2 is not a hypothetical. Real, signed public contracts in this market contain a clause providing for "an annual increase of 5% each Renewal Term." Compounded across a ten-year relationship, that is not a rounding error — it is a second website. If you want to see what your own numbers do over five years, our savings calculator will run the arithmetic, and our pricing page shows what we charge and what we do not.

8. Timeline and milestones

8.1 Proponents shall submit a project schedule identifying, at minimum: discovery complete; information architecture approved; design approved; content migration complete; accessibility testing complete; staff training complete; launch.

8.2 The Municipality's target launch date is [DATE]. Proponents shall state whether that date is achievable and, if not, what date is.

8.3 Proponents shall state, for each milestone, what is required from the Municipality — content, decisions, approvals, staff hours — and by when. Proponents shall state the effect on the schedule of a delay by the Municipality.

8.4 Proponents shall state their typical elapsed time from contract execution to launch on projects of comparable scope, and shall identify the longest such project in the last two years.

Clause 8.3 protects you, and it is worth its weight. Municipal website projects overrun for one reason more often than any other: the vendor was waiting on content from a clerk who did not know it was blocking them and had four other jobs that week. Make the dependency explicit in the schedule so that it is a shared plan and not an ambush.

Clause 8.4 is a politeness that produces an impolite answer. Ask for the longest project, not the average one.

9. Evaluation criteria

9.1 Proposals will be evaluated on the following weighted criteria. The Municipality is not obliged to select the lowest-priced proposal.

9.2 The Municipality may shortlist proponents and require a live demonstration of the content management system, performed by the proponent, using municipal content supplied on the day.

Clause 9.2 is the single cheapest thing you can do to improve this decision. A demo on the vendor's own polished sample content proves nothing. Hand them your actual agenda PDF and watch someone post it.

10. Submission instructions

10.1 Proposals shall be submitted electronically to [EMAIL / PORTAL] no later than [TIME], [DATE], [TIME ZONE]. Late submissions will not be accepted.

10.2 Proposals shall not exceed [20] pages, excluding the completed cost table, the VPAT/ACR, and references.

10.3 Proposals shall include: a completed cost table (Section 7); written responses to Sections 3, 4, 5 and 6, item by item, in the order given; a project schedule (Section 8); three municipal references (Section 5.8); and the name of the individual who will actually manage the project.

10.4 Questions shall be submitted in writing to [CONTACT] by [DATE]. All questions and answers will be circulated to all proponents by [DATE].

10.5 The Municipality anticipates awarding a contract by [DATE].

The page limit in 10.2 is a gift to yourself. If thirty-three proposals arrive and each is sixty pages, you will not read them; you will skim them, and skimming rewards design, not substance. Twenty pages plus a cost table is enough for anyone to say what they do.

Clause 10.3's instruction to answer "item by item, in the order given" is how you make the proposals comparable. Without it you get thirty-three differently-shaped documents and no way to lay them side by side.

The questions most RFPs forget to ask

If you are short of time and cannot rework your whole RFP, add these. Each is one sentence, each demands a written answer, and each has cost a municipality real money by its absence.

"Who owns the source code when the project is complete?"

On a subscription platform, the answer is generally: not you. You have licensed the right to use software the vendor owns, configured to look like your town. When the licence ends, the software goes with it. That may be an entirely acceptable trade — but it should be a trade you made knowingly, not one you discovered in year seven. Get the answer in writing, before award.

"What does it cost us to leave, and how long does it take?"

Ask for the number. If the contract says a data export is available for a fee to be quoted at the time of the request — and at least one major platform's standard agreement does say exactly that — then the price of your exit is set by the party you are exiting, at the moment you have least leverage. Insist on a stated number, and prefer zero.

"What format is our data in when we get it back?"

"You can export your content" can mean a documented database dump with every attachment. It can also mean a ZIP of HTML fragments no other system can read. The second is technically an export and practically a wall. Specify the format in the RFP (clause 6.4) so the answer arrives before the contract does, not after.

"By what percentage do fees increase at each renewal?"

Not "do fees increase" — vendors will say fees are reviewed. Ask for the number that appears in the renewal clause. Signed public contracts in this market carry an annual increase of 5% each renewal term. Over ten years, a 5% escalator raises a $6,000 annual fee to over $9,000, and the total paid to nearly $76,000. That is the whole cost of a new website, spent on keeping the old one.

"If we stop paying, what happens to the website?"

There are two possible answers, and they are completely different products. Either the site keeps running and you simply stop receiving updates, or the site goes dark. Ask which one you are buying.

"Who, by name, will manage this project?"

The people in the pitch are often not the people on the project. Ask for the name, and put the name in the contract.

Two last pieces of advice

Publish your evaluation criteria with the RFP. It is fairer, it produces better proposals, and it protects the award from challenge. It also forces you to decide what matters before you fall in love with a deck.

Do not let the RFP be longer than the thing it is buying. A municipal website is a well-understood object. Twenty pages of clear requirements and a cost table beats sixty pages of boilerplate, every time, for everyone involved — including the vendors, who will bid more carefully on a document that is obviously written by someone paying attention.

If you want a second pair of eyes on a draft, send it to us. We will read it and tell you what is missing, including the parts that would help a competitor beat us. You can get in touch here, and there is no obligation attached to it.

This template is offered as a practical starting point, not as legal advice. Your municipality's procurement rules, state or provincial statute, and your attorney all outrank anything on this page. Take it to them before you publish it.