GIS dashboards for local government: a buyer's guide

Most UK councils buying a GIS dashboard in 2026 will end up with one of three outcomes:

1. A six-figure ESRI implementation they don't have the staff to maintain.
2. An eight-thousand-pound mapping toy that an internal team built in two weeks, then abandoned.
3. A modern, open-source-first dashboard that does exactly what the brief asked for, and is still running fine five years later.

The third outcome is achievable — we've delivered it for councils, NHS commissioners and academic partners. This is the buyer's guide we wish more procurement teams had read before signing.

Define the decision, not the visualisation

The single biggest procurement mistake we see is councils briefing a dashboard around the data they have, rather than the decision the dashboard supports.

A bad brief: "We have flood risk data. We need a dashboard to visualise it."

A good brief: "The flood lead needs to prioritise £400,000 of property-level resilience grants this autumn. The dashboard must rank properties by combined flood + vulnerability score and produce a shortlist suitable for committee approval."

The first brief produces a map. The second produces a tool people will actually open every day.

Budget realistically

Real numbers for a UK council GIS dashboard from a competent UK supplier in 2026:

• Read-only public dashboard from existing open data (e.g. parks + facilities map): £8,000 – £15,000.
• Internal dashboard with role-based access, filters, exports, fed from one or two internal datasets: £18,000 – £30,000.
• Operational dashboard with workflow (task assignment, status tracking, audit trail) on top of the spatial view: £30,000 – £45,000.
• Multi-department platform with shared authentication, multiple dashboards, custom integrations: £50,000+.
• Annual operations + hosting: £3,000 – £12,000 depending on tier.

ESRI ArcGIS Online or ArcGIS Enterprise quotes will land 2–4× higher. The premium is partly real (mature platform, lots of in-house staff already use ArcGIS desktop) and partly licensing rent.

The build vs buy question

Three viable models for a UK council GIS dashboard:

1. ESRI ArcGIS Online / Enterprise

Mature, comprehensive, expensive. Sensible if your council already has ArcGIS Desktop seats, your in-house GIS team is on ESRI training, and you need a wide range of out-of-the-box capabilities. The lock-in is real — both the licence cost and the data formats. Procurement is straightforward via existing G-Cloud framework agreements.

2. Off-the-shelf SaaS (Esri Sites, ArcGIS Hub, Mapbox Atlas, CARTO)

Faster to launch, narrower in scope. Right for a public-facing dashboard with limited customisation needs. Wrong for anything that needs custom workflow.

3. Bespoke build on open-source stack (MapLibre + QGIS workflows + PostGIS)

Most flexibility, lowest ongoing license cost, most reliant on you having a competent supplier. Our preferred approach for councils — your data stays portable, no usage-based vendor pricing, and the dashboard can be handed over to any other supplier if needs be.

What to look for in a supplier

• Live UK references. Click around the dashboards they've shipped. Not screenshots — live URLs.
• Open data competence. They should be able to talk fluently about OS OpenData, ONS, EA flood zones, OSM, Copernicus — not just whichever proprietary dataset they're selling on top.
• WCAG knowledge. Public-sector accessibility regs apply. Ask how they meet WCAG 2.2 AA on map-based UIs (it's harder than non-map UIs).
• Cyber Essentials Plus. Most councils now require it.
• Clear handover plan. What happens if your council changes supplier in three years? The answer should be "you take the repo and run it elsewhere," not "you start over."

Procurement traps to avoid

The dashboard-with-no-data-pipeline trap

A vendor demos a polished dashboard at the pitch. Two months after launch, the data underneath is six weeks stale and nobody can work out how to refresh it. The dashboard becomes shelf-ware.

Fix: insist that the proposal explicitly covers the data update pipeline. Who fetches it? On what schedule? Where does the refresh happen? Who gets alerted when it breaks?

The "we'll integrate with [internal system]" trap

Most internal council systems have either no API, or an API that requires a series of meetings with the system's vendor to access. Vendors rarely scope this work properly.

Fix: scope integrations as a separate work package, with a specific lead from your internal systems team. Don't accept "we'll figure that out in week three."

The accessibility-as-an-afterthought trap

Map-based dashboards are hard to make accessible. Keyboard navigation, screen-reader support, focus management, alternative data views, sufficient colour contrast — these are not boxes you tick at the end. They shape the architecture.

Fix: require WCAG 2.2 AA compliance in the contract, with sign-off based on an independent audit. Budget for that audit.

The vendor-lock-in trap

Some vendors price the v1 attractively, then make v2 contingent on staying with them. The lock-in is usually in the data layer: proprietary formats, hosted infrastructure that's hard to migrate.

Fix: require open formats (GeoJSON, PostGIS, GeoTIFF) and confirm in writing that the data and code are deliverables you own.

A reference architecture we like

For a typical bespoke council dashboard, our standard reference architecture:

• Data: PostGIS database on Supabase or a council-hosted VM. Open data ingested via scheduled Python jobs.
• Tiles: Self-hosted vector tiles via Protomaps PMTiles, or OpenFreeMap.
• Map: MapLibre GL JS — open-source, no usage fees, smooth WebGL rendering.
• Front-end: Next.js or pure static HTML, depending on auth complexity.
• Hosting: Vercel + Supabase + Cloudflare CDN.
• Analytics: Plausible (GDPR-compliant, no cookie banner needed).
• Accessibility: Independent WCAG 2.2 AA audit before launch.

This stack delivers a fast, accessible, brand-aware dashboard with no per-user licensing — and the entire stack is portable to another supplier if your council ever needs to change.

The actual question to ask in a supplier interview

Skip "tell us about your experience." Ask this instead:

Tell me about a dashboard you delivered that didn't get the usage you expected. What did you learn?

Suppliers who answer this honestly tend to be the ones who'll deliver something useful. Suppliers who claim every project was a runaway success are the ones who'll deliver the shelf-ware.