Case study

Seattle Neighborhood Pulse

A live civic dashboard that shows what Seattle residents report to the City, where, how it is changing, how fast the City responds, and whether it responds equally across the city.

Next.js, TypeScript, MapLibre GL, Recharts, Tailwind CSS, Vitest, GitHub Actions, Vercel

Code Live demo

The problem

The City of Seattle publishes every customer service request since 2013, about 2.53 million rows refreshed daily. On the open-data portal it is a raw table, so a resident or a reporter can’t easily answer basic questions: what is being reported, where, whether it is getting worse, and how quickly the City responds.

Constraints

Every number comes live from the City’s Socrata API. No database and no copy of the dataset.
The main dataset has no resolution date, and the API returns at most 50,000 rows per page.
Numbers must not mislead: comparisons per resident, changes over equal-length periods, and samples always labelled as samples.
Works from a 360-pixel phone to a wide desktop, and meets WCAG 2.1 AA.

What I built

A single Next.js application with three server endpoints: the dashboard, response times and the equity analysis. The server asks the City’s API to aggregate, so the browser receives about 76 KB of results, never the raw dataset.

City of Seattle open data (SoQL API)

Next.js server endpoints

15-minute cache

Map, charts and filters in the browser

Each filter change runs ten aggregate queries in parallel. Results are cached for 15 minutes, identical requests share one upstream call, and failures are never cached.
Filters live in the page address, so any view can be bookmarked or shared, and every filter updates the map, metrics, charts and lists together.
A map with neighborhood shading by count or per 1,000 residents, a density heatmap, and clustered markers for the newest 2,000 requests.
Response times for the five request types the City tracks, and an equity panel that compares closure speed across the City’s Racial and Social Equity Index quintiles.
Neighborhood boundaries, population and census tracts ship as static files generated by scripts from the City’s GIS services.

Decisions and trade-offs

Response times are measured only on requests old enough to judge (at least 30 days), so a busy recent week doesn’t look slow just because new requests haven’t had time to close.
The equity panel compares each group with what its mix of request types predicts, with 95% margins, so an area isn’t labelled slow because it reports more of the slower types.
Neighborhoods with fewer than 5,000 residents are shown separately rather than ranked, because a few requests swing their per-resident rates widely.
Changes use neutral arrows rather than red and green, because more reports is not necessarily worse.
Grouping requests into small map cells was checked against exact locations before building on it: 1.7% of requests changed group, about the same as moving each point 11 metres.

Results

Live on Vercel with neighborhood search, response times, the equity panel and a mobile-first layout.
132 automated tests, including real API responses captured as fixtures. GitHub Actions runs type checks, linting, tests and a build on every pull request, and branch protection requires them to pass.
No accessibility violations under axe-core at desktop and phone widths.
The equity calculation matched an independent recomputation within 0.3 percentage points on 35,287 requests, and response times matched a hand calculation (abandoned vehicles: 5,869 requests, median 9 days to close).

What I'd do next

Extend response times beyond the five request types if the City publishes more tracking data.
Move the cache to a shared store, since each serverless instance currently warms its own.