42 questions to ask any website platform or CMS vendor before you sign: accessibility, roles and approvals, sign-in, security, data ownership, exit, support, contract terms and cost. With what a good answer sounds like.
Vendor demos are built to show what a platform does well. This checklist is for finding out the rest before you sign. It has 42 questions in nine groups, each with a note on what a good answer sounds like and what should worry you. It works for a government agency, a university, a hospital system or a company running many sites. Copy the questions into your own evaluation sheet and ask every vendor the same ones.
Before you talk to vendors: three things to settle internally
Who will publish? Count the people and departments. A platform that suits five web staff can fail with two hundred occasional publishers.
What must the platform connect to? List payment, forms, booking, records, maps, recruitment and search tools, and decide which ones are linked and which must be embedded.
What is your deadline, and why? If you are a US state or local government, the ADA Title II web rule now applies from April 26, 2027 (50,000 people or more) or April 26, 2028 (smaller entities and special districts). See the Title II deadline guide.
A. Accessibility (questions 1 to 7)
Which accessibility standard does your public output target, and how do you know it meets it? Good: names a version and level (for example WCAG 2.1 or 2.2 AA) and a dated test. Worry: "fully ADA compliant" with nothing behind it.
Can we see your most recent accessibility conformance report, with the date and who tested? Good: a document with known issues listed. Worry: no known issues at all, or no report.
Is the editing interface accessible to staff who use a screen reader or keyboard only? Many vendors only test public pages.
What does the editor do to stop publishers adding defects? Look for required alt text, heading checks, warnings on vague link text and limits on colours.
How fast do you fix an accessibility defect in your templates, and will you put that in the contract? Good: a number of days, in writing.
Do you sell or recommend an accessibility overlay? An overlay adds a toolbar on top of the page; it does not fix the code underneath. A vendor relying on one is a warning sign.
Can we run our own audit, and will you help fix what it finds? The answer should be yes without a fee for defects in their code.
B. Roles, approvals and governance (8 to 13)
What roles exist, and what can each do? Ask for the actual list. Custom roles are rarer than demos suggest.
Can a publisher be limited to one department's section or one site?
Can approval before publishing be required, and for whom? Ask whether it is one step or several, and whether it can be switched on for some publishers only.
What is recorded in the audit log, how long is it kept and can we export it? Useful for public records requests and for investigating a bad edit.
How are brand elements protected? Can a department change the header, colours or footer, or only its own content?
Can we schedule publishing, expiry and review reminders? Stale pages are the most common governance failure.
C. Sign-in and access (14 to 17)
Can staff sign in through our identity provider, and can we require it? Ask them to show it working with your provider, not a slide.
Is multi-factor authentication available for every account?
What happens to an account when someone leaves? Removing access should be one step and immediate.
Can vendor staff access our content, and is that access logged?
D. Security (18 to 22)
Which independent audits or certifications do you hold today? Ask for the report or certificate, its date and its scope. "In progress" is not held.
How are vulnerabilities found and patched, and how quickly?
How soon will you tell us about an incident affecting our data, and how? Get a number of hours in the contract.
Where is our data stored, and who are your sub-processors? If location matters to you, get it in writing.
Will you complete our security questionnaire? A vendor that refuses, or asks you to rely on a summary page instead, is hard to hold to anything later.
E. Reliability and performance (23 to 26)
What availability will you commit to in the contract, how is it measured, and what is the remedy? A marketing figure is not a commitment.
What happened in your last significant outage? A vendor that answers plainly is a better sign than one that claims none.
How are backups taken, kept and tested? Ask when a restore was last tested.
How does the site handle a sudden traffic spike?
F. Data ownership and exit (27 to 32)
Who owns our content, media, form submissions and analytics? The answer must be you.
Can we export the whole site ourselves, today, without asking you? Ask them to do it in the demo.
What is in the export? Text only, or also media, page structure, templates and code? Could another vendor run the site from it?
Does export cost anything, during or after the contract?
Do our domain names and DNS stay in our accounts? If the vendor holds your domain, leaving gets harder.
What happens to our data when the contract ends? Look for a transition period, a final export and written confirmation of deletion.
G. Building and changing sites (33 to 36)
How long does it take to stand up a new department or program site? Ask them to do one live.
Which changes need the vendor, and which can our staff make? Count how many routine changes would be billable.
How do you handle forms, and can submissions be sent to our own systems?
Can we use our own domain for every site, including department sites?
H. Support and training (37 to 39)
What support hours and response times are in the contract?
Is training included, and can we reuse the materials internally?
Who is our named contact, and what happens if they leave?
I. Contract and cost (40 to 42)
What is the total cost over five years, including renewals? Ask for it in one table with one-time and recurring items split.
What limits change the price? Users, sites, pages, storage, traffic and AI use are common ones.
What is the cap on annual price increases, and can we leave without penalty at renewal?
How to score the answers
For each question, give 0 (no or not shown), 1 (yes, but described only) or 2 (shown working in the product). Questions 1, 2, 27, 28 and 40 decide most outcomes, so weight them double. A vendor that scores well on slides and poorly on "shown working" is telling you something.
Score
Meaning
0
Not available, not answered, or only on a roadmap
1
Answered in writing but not demonstrated
2
Demonstrated in the product, or backed by a dated document
If you are writing a formal solicitation, our government website RFP template turns the most important of these into numbered requirements with a 100-point rubric.
How We.Inc answers some of these
We would rather you check us against this list than take our word for it. Today, our white-label platform gives you: owner, admin and member roles plus per-client permissions (question 8 and 9); a single approval step before a site publishes (10); an audit log of organisation actions (11); your own domains for the portal and each site (36); and full code download or sync to your own GitHub (28 and 29). Sites are built with AI, so accessibility is something your team must test before publishing; we do not claim conformance. We do not claim security certifications or a contractual availability figure. To go through the rest with us, book a demo and bring this checklist. See also the We.Inc white-label platform.
We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.
Product
AI Website Builder: Describe a site in plain English; it's live in minutes