~$Ajay Sogi
← All work
Case study · AtkinsRéalis

PinPoint Consultation

A reusable map-based consultation platform that helps public bodies explain proposed infrastructure schemes and gives residents a way to share their feedback.

Headline result
On the record
resident feedback tied to the places it affected, kept as evidence and exported for reporting.
01
$ cat problem.md

The problem

Government bodies and organisations such as Heathrow needed to explain planned infrastructure work and gather feedback from residents. The application had to be accessible to the general public, with maps helping people understand what was proposed around them.

PinPoint replaced a manual process with a map-based consultation product. It connected comments to affected locations, stored responses digitally and exported the data for reporting and compliance work.

02
$ cat constraints.md

Constraints

  • —The application had to be accessible and functional for the general public, who needed to understand proposals and contribute feedback.
  • —Each client needed separate ownership of its consultation data, with privacy and straightforward deletion after the consultation ended.
  • —As the team’s frontend specialist, I connected UI/UX decisions with implementation and discussions about the wider architecture.
  • —The team needed a low-cost starting point with flexible data relationships, hosting and backend functions in one managed platform.
03
$ cat ownership.md

What I owned

I was a key developer and the team’s frontend specialist. I helped shape the architecture with the system architect and bridged UI/UX and development. I took ownership of ensuring we delivered an accessible, usable application that helped the public understand infrastructure proposals.

04
$ cat decisions.md

Key decisions

  • 01Choose Vue after comparing Angular, React and Vue, alongside Laravel for the backend. Firebase added flexible data, hosting and functions, but increased reliance on managed services.
  • 02Deploy a separate Firebase instance for each client. Isolation supported privacy, data ownership and eventual deletion, but meant operating multiple product deployments.
  • 03Tie feedback to places on an interactive map. Location-specific comments improved context, but the interaction still had to remain accessible and usable for the general public.
05
$ cat flow.md

How it worked

├─Deploy a client instanceEach consultation gets separate hosting and data storage.
├─Publish affected zonesThe map shows affected areas and their infrastructure impacts.
├─Explore the scheme mapResidents inspect locations and read the relevant details.
├─Place a feedback pinA resident attaches an opinion to a location on the map.
├─Store isolated responsesFeedback stays within the client’s separate database.
└─Export consultation dataResponses are exported to CSV for reporting and compliance.
06
$ cat changes.md

What changed

-manual collation and administrative handling of feedback
+client-isolated storage for consultation responses
+map comments linked directly to affected locations
+consultation data exported to CSV for reporting
+reusable product deployed as separate client instances

PinPoint replaced manual collation with client-isolated digital responses and CSV export. Its reusable deployment model supported schemes including Heathrow and council highway work.

07
$ cat reflection.md

Reflection

Separating each client’s data simplified privacy, ownership and deletion, but increased the operational work involved in maintaining separate deployments.

If I rebuilt PinPoint, I’d invest earlier in automating the creation, configuration and eventual removal of client deployments to reduce that repeated operational work.