Pittsburgh Food Access Map

A capstone project built for and currently deployed with the Pittsburgh Policy Initiative — helping residents find food assistance across nearly 800 locations citywide. No account needed. Search, filter by type or distance, check what's open right now, and get directions. PPI staff manage the full dataset through a role-gated admin dashboard.

The Problem

Food insecurity is a persistent challenge in Pittsburgh, with many neighborhoods lacking consistent access to affordable, healthy food. In 2019, Code for Good Pittsburgh built a map to visualize food deserts and resources, but it fell out of maintenance. The Pittsburgh Policy Initiative set out to rebuild it — not just as a resident-facing tool, but as a platform staff could maintain without a developer and where community members could contribute updates directly.

My Role

Lead developer on a small team. Responsible for the full-stack architecture, deployment infrastructure, and most of the feature work.

What I Built

Filtering by type, distance, and hours. Users can narrow results by resource type (food pantry, food bank, community fridge, and more), filter by distance from their location, and toggle to show only currently open sites. Hours are stored as structured JSON per day and checked client-side against the current time. That same data structure powers an admin-facing hours editor. These filters address the most common frustration with resource finders: wading through irrelevant or closed locations.

Community suggestion pipeline. Anyone can submit a new resource location for review. Admins can approve, reject, or promote a suggestion into a live map entry in a single workflow. The suggestion retains a link to the created resource for a clean audit trail. This keeps the dataset accurate without requiring staff to source every update themselves.

Containerized deployment with a closed security model. The full stack ships as two Docker containers behind an external reverse proxy, with the database volume-mounted so data persists across rebuilds. Admin registration requires an existing admin session as there's no open self-registration endpoint. Production uses HTTPS-only session cookies with secrets injected via environment variables. Pittsburgh residents will depend on this daily, so the deployment had to be simple to maintain and hard to break.