Every day landed a demoable increment
The plan mapped each acceptance criterion to a specific day, with a traceability table, so progress was reviewable against the contract rather than against a feeling.
A 2D wayfinding and site-awareness web application for a large construction programme: mapped points of interest and work sectors, live GPS positioning, and routing between any two points over an authoritative GIS path graph that reroutes when a path is closed. Delivered as a phased proof of concept against a contract acceptance list.
The engagement was scoped against a numbered contract list: render 2D map tiles, interact with a GIS service to determine routing, represent the user accurately on site from GPS, pan by dragging, accept two locations, display the optimal route between them, run on modern browsers, and be written in TypeScript. Everything built served those eight points first; anything beyond them was marked as a stretch and tracked separately.
The plan mapped each acceptance criterion to a specific day, with a traceability table, so progress was reviewable against the contract rather than against a feeling.
Routing decisions come from a server-side GIS path graph rather than from client guesswork, which is what makes the result defensible to the people who own the site data.
Parts of a construction site have no roads and no public network at all. A client-side snap engine was retained for those, and for offline use.
A site map is only useful if it models the things site teams argue about: where work is happening, what is closed, what is dangerous, and how to get past it.
Modelled as strict types rather than loose JSON: points of interest, sector polygons with status, traversable paths, and the equipment and people moving between them. Category filters let a user reduce the map to what they came for.
Live GPS with heading and accuracy, a recenter control, and graceful handling of denied permission or no signal — the states that actually occur on a site with steel everywhere.
Closures are live state, not a static layer. A route requested while a path is closed comes back around it rather than through it.
Hazard zones sit alongside a separate predicted-hazard layer driven by a cloud model, kept visually distinct from confirmed hazards so nobody mistakes a prediction for a fact.
Wind and air quality read alongside the map, because on an open site in heat they change what work is safe today.
Site staff can place and edit points and zones directly, with editing rights separated from viewing rights.
The client holds no privileged credentials. A small TypeScript proxy fronts the mapping and routing calls and any model endpoints, and ships as a single container. Map keys that must be client-side are referrer-restricted.
The deployed application sits behind an identity-aware proxy, so the routing service can be reached same-origin on the session — no second sign-in, and no cross-origin surface to secure separately.
The map is a declarative component with overlay layers driven from application state, so points, sectors, routes and closures stay consistent with each other instead of drifting as imperative layers do.
Service responses pass through an explicit parse-and-map layer before reaching component state, which keeps a change in the routing service from silently reshaping the UI.
What this proves: a site operations map can be built to a contract acceptance list, deployed behind real access control, and still stay honest about the difference between a confirmed hazard and a predicted one.
Both of these builds answered the same question from different directions: authoritative geospatial routing for operational use, and photoreal capture for comprehension and stakeholder communication. They are complementary, not competing.