A town website fails in one of two ways: nobody on staff can change it, or everybody can and nothing is reviewed. Below is what every Queantic site already does about the first, and — stated separately and honestly — what we would have to build for the rest.
What you get on every site
These are not add-ons and not a tier. Every Queantic site is hosted, updated, backed by monitoring and measured, whoever it belongs to.
Included
- A WordPress site your staff already know how to use. News, notices, meeting dates and department pages are posts and pages. No ticket to us to post a closure.
- Roles and a review step, out of the box. WordPress’s own Editor, Author and Contributor roles — and a Contributor’s page waits for an Editor to publish it, which is an approval gate you do not have to build. We create and set the accounts; the handed-off owner role deliberately cannot manage users.
- Hosting, SSL, updates and monitoring. Run by us on U.S. infrastructure, checked every five minutes, with the history public on our status page.
- Residents are not tracked. No cookies, no stored identifiers, no profiles — so no consent banner on a government site, and nothing about a resident for anyone to request.
- Your own domain, including a .gov. Bring the one you have on any plan. SSL is issued and renewed for it automatically.
What we build for you
Quoted as named line items on the pricing sheet, so your board sees what each one costs rather than a single number with a story attached. Nothing here is a switch we flip — it is work, and it is priced as work.
Built to order
- Agendas and minutes archive. Meetings by body and by year, each with its agenda, packet and minutes, searchable and permanently linkable. Build work, not a module we switch on.
- Document centre with search. Ordinances, budgets, forms and reports, categorised, with full-text search across them.
- Emergency and closure alert banner. A banner any authorised editor can raise site-wide in one action and take down the same way.
- Department structure and per-department editors. Scoping an editor to their own department’s pages goes beyond WordPress’s built-in roles and is work we quote.
- Language selector. Chosen with you — machine translation is quick and imprecise, human translation is neither. Which one your residents are owed is your call, and it changes the quote.
- Forms and payments. Permit and request forms with routing; online payments integrated with the processor you already hold a merchant account with. We do not become your processor.
What your board sees each month
One report, in plain language, built from the same analytics the site collects as it runs. No tag manager, no sampling, and no second tool to licence.
| On the report | What it answers |
|---|---|
| Sessions, real and automated, separately | What your traffic figure actually represents |
| Top pages and top exits | Whether residents find the thing they came for |
| Search terms on your own site | What residents cannot find — the most useful list on the report |
| Form submissions by type | Permit requests against general enquiries |
| Device split | How much of your audience is reading this on a phone |
| Ranked recommendations | The three changes most likely to cut your phone calls |
The report is one of the things we are still building to a shape a board can accept without a covering note. Ask for the current version when you ask for the quote, and judge it rather than this paragraph.
Residents and visitors are not profiled
Queantic's analytics set no cookies, store nothing in the browser, and build no cross-site identifier — so a Queantic site needs no consent banner for them, and there is no visitor profile for anyone to request, sell or leak. Traffic is separated into real and automated before it reaches a number you report. The architecture is described on how the analytics work.
Accessibility
We build to WCAG 2.1 Level AA and test every release against it: automated scans plus manual keyboard and screen-reader passes. We have not been independently audited yet, so we claim no conformance level and publish no Accessibility Conformance Report — both are in progress and neither is something to take our word for. What we do today, how we test it, and how to report a problem are on our accessibility page.
Hosting, uptime and the paperwork
Run for you
- U.S. hosting, SSL issued and renewed automatically
- WordPress, plugin and security updates are ours
- Monitored every five minutes, with a public 90-day history per component on our status page
- Unlimited traffic — a busy season is never a bill
For procurement
- Itemised one-time build and annual hosting and support
- You own the site, the content and the data; full export on request
- A written handover plan, so leaving is a procedure and not a negotiation
- The vendor packet is on our procurement page
Questions town clerks and district managers ask
Do you already have an agendas and minutes module?
No. It is build work and it is quoted as a line item. We would rather lose a bid on that than win one on it.
How many staff can edit, and can we require approval?
As many as you need, at no per-seat cost. Approval uses WordPress’s own review step: a Contributor submits, an Editor publishes. Restricting an editor to one department’s pages is additional work.
Do we need a cookie banner?
Not for anything Queantic does. Our analytics set no cookies and store nothing in the browser. A banner only comes back if you add a third-party embed that needs one — a video player, a map, a social feed — and we will tell you which ones do.
The rest — domains, editors, outages, cookie banners, pricing — are answered on the public-sector overview.
Two ways to start
Tell us what you need and we will send an itemised quote. If you already have an RFP or an ITB out, send it and we will answer it in the format you asked for — including three written quotes if that is what your policy requires.