Web GIS portal builds
Custom web interfaces over spatial data — for asset operations, public-facing maps, or internal planning.
A Web GIS portal puts spatial data in front of people who aren’t GIS specialists — operations teams, field crews, planners, customers. Done well, it replaces the spreadsheets and printed maps that fall out of date five minutes after they’re produced.
We build Web GIS portals on the platform that fits the project. Geospatial work is delivered through our partner Geodars.
What a portal actually does
Three jobs, in priority order:
1. Make spatial data discoverable to the people who need it. A field crew shouldn’t need to know GIS software to find a chamber location or a fibre route. The portal is the interface.
2. Surface real-time operational state. Modern portals integrate with asset systems, work orders, sensor data — the map is a window into operations, not a static snapshot.
3. Capture data back from the field. Tablet-based forms for inspections, fault reports, asset additions. The portal is bidirectional.
A portal that only does (1) is a digital map. A portal that does all three is an operational tool.
Platform options
We build on the platform that fits:
ArcGIS Online / Enterprise — for organisations already in the ESRI stack. Tight integration with ArcGIS data, Field Maps, Survey123. Subscription model.
Leaflet / Maplibre + Geoserver — open-source stack. Heavy-customisation friendly, no per-seat licensing, runs against PostGIS or any OGC-compliant data source.
OpenLayers — for projects that need fine-grained map control or specific OGC compliance.
Hybrid — many real deployments mix — ArcGIS for asset of record, Leaflet for a public-facing layer, etc.
The choice isn’t dogma. We pick what serves the project.
What’s in a portal build
A complete portal delivery covers:
- Front-end map application — built to the chosen platform, styled to the project’s visual identity
- Layer management — base maps, asset layers, operational layers, all configured with appropriate styling
- User access control — who sees what, who edits what, role-based permissions
- Backend integration — connection to PostGIS, SDE, or whatever spatial source is authoritative
- External integrations — work orders, asset systems, sensor data
- Mobile / tablet responsive — the portal works on field devices, not just desktops
- Deployment — to client infrastructure or managed hosting
- Documentation — admin guide, user guide, developer reference for future extension
- Training — for the team that’ll administer and use the portal
Use cases we typically build for
- Utility asset operations — water, power, telecom asset records accessible to field crews
- Fibre network management — route, asset, splice records integrated with operations
- Project tracking — construction progress mapped against design, accessible to stakeholders
- Public-facing service maps — coverage maps, service availability, applicable to broadband providers showing service area
- Internal planning portals — shared spatial context for cross-team planning
Inputs we need
A productive portal build runs on:
- Use case — who uses it, for what
- Existing data sources — what spatial data exists, in what systems
- Authentication context — does this integrate with corporate SSO, internal user directory, public access
- Performance requirements — concurrent users, response time expectations
- Mobile / field requirements — what devices need to work, online or offline-capable
- Visual identity — branding, styling preferences
Common pitfalls in outsourced portal work
Building the portal before the data is right. A portal built over inconsistent or stale data exposes the data quality problem. We assess data state at the start and where needed run a data migration and cleansing phase before portal build.
Generic styling. Portals that look like every other Leaflet implementation feel disposable. We style deliberately to match the organisation’s visual identity.
Missing the field workflow. Portals built for desktop without thought for tablet use produce an unloved tool. We design for the actual usage context, not the office chair.
No documentation handover. A portal handed over without operational documentation becomes a liability when the building team rotates off. We document admin, user, and developer flows as part of delivery.
Typical timelines
- Single-purpose portal (e.g. asset viewer for one team) — 4-8 weeks
- Multi-purpose portal with editing, integrations, multiple user roles — 8-16 weeks
- Enterprise deployment with SSO, auditing, large user base — 16-32 weeks
- Iterative build — most portals continue evolving post-launch; we structure for that
How we deliver
Geospatial work runs through our partner Geodars. The team builds Web GIS portals across multiple stacks (ArcGIS, Leaflet, Maplibre, Geoserver) and runs the operational side through deployment.
Talk to us about a portal project
Tell us the use case, the platform direction (or whether that’s TBD), and the user base. We’ll scope, price, and discuss the right delivery approach for the project.
Typical deliverables
- Custom Web GIS portal (ArcGIS, Leaflet, Maplibre, or Geoserver-based)
- Layer configuration and styling
- User access and permissions
- Integration with backend spatial database (PostGIS / SDE)
- Mobile and tablet responsive design
- Operational documentation and handover
Who buys this
Network operators, utility owners, infrastructure project teams, and organisations who need spatial data accessible to non-GIS-specialist users.
Talk to us about delivery options
Tell us what you need delivered, what your timeline is, and what format the downstream team needs the output in. We'll come back with scope, price range, and proposed approach.