Should a UK council build a GIS dashboard in-house or hire a studio?
Every council with a planning department, an environment team or a parks division eventually faces this. The honest answer depends on three internal questions you can answer in 20 minutes, before you ever write a tender.
Every UK council with a planning department, an environment team or a parks division eventually faces this question. Building a GIS dashboard in-house feels cheaper. Hiring a studio feels safer. Both can be wrong. This post sets out the three internal questions that decide it — before you ever write a tender.
- In-house if you have at least one full-time GIS specialist with development time protected from BAU, and a senior IT contact willing to host it inside your existing tenancy.
- Studio for everything else — especially anything customer-facing, anything that needs uptime, anything subject to accessibility audit, or anything you want to ship inside six months.
The three questions
1. Who maintains it after your specialist leaves?
Most council GIS dashboards we've audited were built by one talented person who left within three years. The dashboard outlived them by a decade, became impossible to update, and was eventually retired or replaced at twice the cost it would have taken to procure it externally in the first place.
Before you build in-house, ask: who maintains this in five years? If the honest answer is "the same one person," you're building a key-person-dependent system on public money. That's a procurement failure dressed as a saving.
2. Who does it serve?
Internal-only dashboards (officers looking at planning applications, parks teams tracking trees) tolerate clunky UX and occasional downtime. Public-facing dashboards (residents looking at consultation maps, applicants tracking permissions) do not.
Public-facing dashboards have to meet:
- WCAG 2.2 AA accessibility, audited and documented
- Welsh-language parity if you're a Welsh authority
- Mobile responsiveness — most public users hit councils on phones
- Browser support down to two major versions of every modern browser
- Uptime measured in "four nines or better," not "works most days"
- Performance budgets — public-facing pages on slow rural broadband
In-house teams often build internal-quality dashboards and then publish them externally, hoping nobody notices. The Equality and Human Rights Commission notices. So does the press.
3. What's your accessibility audit story?
Under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, every council dashboard published externally needs a written accessibility statement, regular audits, and remediation evidence.
Most council in-house dashboards we've audited fail at least three WCAG 2.2 AA criteria around colour contrast, keyboard navigation, screen-reader semantics for map controls, and form-field labelling. Fixing those after the fact is harder than building accessibility in from day one.
A studio with public-sector experience builds accessibility into the foundation. An in-house team without an accessibility specialist will need to learn it, then retrofit it.
Cost honest comparison
In-house build cost
- Senior GIS developer time at £350–£500/day, six months: £45k–£60k
- Designer time (often missing): £8k–£15k
- Accessibility specialist or audit (often missing): £3k–£8k
- Hosting on existing tenancy: £0 (treated as sunk cost)
- Ongoing maintenance: 10–20% of build cost per year
Apparent cost: £56k–£83k for v1. Real cost when you include the parts most in-house builds skip: £75k–£110k.
Studio build cost
- Fixed-price discovery + build: £35k–£75k
- Hosting, monitoring, accessibility care plan: £600–£1,500/month
- Annual contract: ~£7k–£18k
- Includes monthly feature increment, accessibility re-audit, dependency patching
Apparent cost: £35k–£75k for v1. Real cost over three years including operations: £55k–£120k.
Studio wins on real total cost most of the time. In-house wins when you have a genuine surplus of GIS developer time that would otherwise sit idle — which is rare in 2026.
What "good" looks like in 2026
- Open-source map base (MapLibre GL JS or OpenLayers — never a paid Mapbox-only stack for a council)
- Vector tiles hosted on your own infrastructure or a VFR (Vector Tile Service) you can swap out
- OS OpenData and OSM as primary basemaps, premium OS API only where needed
- Layer toggles, legend, geolocation, search by postcode and gazetteer
- Mobile-first responsive layout
- WCAG 2.2 AA across map controls (keyboard-navigable, screen-reader-friendly map UI)
- Export to GeoPackage, CSV, GeoJSON
- Print-friendly view
- Permissions model for officer vs public views
- API hooks for integration with your planning portal, parks asset register, etc.
Procurement red flags
Watch for these when reading vendor proposals:
- Proprietary basemap lock-in (only works on the vendor's tiles) — you're hostage forever
- No accessibility statement in the proposal — they'll discover it's a requirement after signature
- Custom JavaScript framework nobody else knows — see "key-person dependency" above
- Hosting on the vendor's own cloud with no exit plan — when they go under or get acquired, your data goes with them
- No source-code escrow — same reason
- One-off fee with no maintenance retainer — sounds cheap, ends in a dashboard nobody updates
How BozApps handles council work
Bozmaps (our parent firm) has delivered geospatial work for UK councils since 2024. BozApps wraps the engineering side: production web hosting, accessibility audit, on-call response, and a monthly feature increment. Fixed-price discovery, fixed-price build, predictable monthly operations cost. Open-source stack, source code in your GitHub org, exit clean if you ever want to take it in-house.
Most council engagements run £40k–£70k for v1 with £900–£1,400/month operations. Faster than any in-house build, cheaper than any Tier-1 GIS vendor.