Aptli CMS · municipal web
A public website your staff actually run.
A modern, accessible municipal site on a content system with no release cycle — and the same platform's resident service hub embedded in it, under your own domain.
Why it's different
Four things that decide how a municipal site actually runs.
Most website problems aren't design problems. They surface a year later, in how the site is maintained.
No vendor release to absorb
Most municipal sites run on someone else's platform, so an update arrives on their schedule and a hosting problem becomes a ticket with their support desk. This CMS is ours. There is no third-party release cycle standing between you and a fix.
Edit once, live immediately
Staff log in, edit, and publish. No redeploy, no build step, no waiting — the page is live the moment it's saved. Pages are server-side rendered, so speed and search behaviour hold up at full site scale.
Migrated intact, not rebuilt from scratch
Every existing page, document, and friendly URL is carried across and verified before anything new is layered on top, with redirects catching whatever moved. Nothing loses its address, so rankings and inbound links come with you.
Accessible by build, not by patch
WCAG 2.1 AA is engineered into the templates at the architecture stage rather than retrofitted before launch. Keyboard navigation and screen-reader support are native to the shell, and every content type inherits them.
The service hub
Add the two-way half: forms, reporting, and work that gets done.
A website answers questions. The hub is what happens when a resident needs something — reporting an issue, submitting a form, following what happened next. It's the same Aptli platform, white-labeled and served under your own domain.
- A resident snaps a photo, the location fills itself in, and AI picks the right form. No account, no app store.
- The report lands as a work order against the mapped asset, routed to the right team, with status flowing back automatically.
- Drop it into an existing site with a single script tag, or run it as native pages of the new one.
What's included
The editing surface, and what sits behind it.
Content management
Rich-text editing, a media and document library with per-kind size limits, hierarchical pages whose navigation derives from the page tree, and role-based permissions across administrators and editors.
Review before it goes live
An approval workflow where an editor submits and an administrator publishes, plus full revision history on every document — see what changed between versions, and restore any earlier one.
Site-wide search
Weighted, relevance-ranked search across every published page, notice, event, and document in the active language, with a header search affordance and zero-result tracking.
Notices and events that know where and when
A non-technical staff member attaches a location and a time to an event directly, through a simple form. Public notices and community events stay separate streams, so neither buries the other.
Bilingual, genuinely mirrored
English and French as real, indexable, linkable pages in each language — mirrored content rather than a browser translate widget layered over the top. Additional languages are scoped per engagement.
Canadian-hosted and hardened
Canadian data centres, mandatory two-factor authentication for every staff account, server-side rendering with no exposed admin surface, and content served through a CDN edge with DDoS protection.
See the CMS and the hub together.
A walkthrough of the editing surface, the migration path, and the resident hub — with straight answers on what ships today and what we'd build for your engagement.