Inspiration
We're both born New Yorkers, and we've been there. Food insecurity doesn't have a face — it's a neighbor, a coworker, someone's grandmother, someone's kid. It moves through this city quietly.
What sent us at this specific problem is a gap we kept running into. Every food resource map in New York tells you where something is. Not one of them tells you whether you can actually get there. If you use a wheelchair or a walker, or you're pushing a stroller, the address is the easy part. The elevator at the station that serves it is the hard part. We wanted to build the thing that answers the question people are really asking.
What it does
Ask in plain language, in any language — "free lunch for my 6 year old in the Bronx," "mi mamá usa silla de ruedas y necesitamos comida hoy." The app returns free summer meal sites with a verdict on each one: green, amber, or red.
The verdict isn't a rating. It's a calculation across whether the site's season is open, whether it operates on the date you picked, whether the nearest ADA-accessible station's step-free path elevators are in service, and whether a human has verified the entrance. Every claim on screen shows its source dataset and the date it was pulled.
Nothing is green. Green requires human verification, and no site has it — because that verification layer doesn't exist anywhere in New York City. That's not a limitation of the app. That's the finding.
Each result also carries "Along the way": nearby libraries, street trees for shade, benches for anyone who needs to rest, restrooms, accessible pedestrian signals, and 311 street-condition reports for the corridor between the station and the site.
How we built it
Two people, two days, one repo, strict file ownership so our AI agents never collided.
The data spine is USDA's Summer Meals Site Finder for the sites, MTA's station and elevator/escalator feeds for accessibility, NYC Open Data for context layers, and Census ACS plus USDA's food access atlas for neighborhood signals. A serverless function parses the natural-language query — the model extracts intent only and never generates site data, because a hallucinated address for a hungry family is the worst thing this app could do. When the parser is unavailable, a local keyword matcher takes over and the app keeps working with zero network calls.
Addresses are geocoded client-side and never leave the browser.
Challenges we ran into
The hard part wasn't building. It was catching the things that looked true and weren't.
We built a feature flagging where MTA reports elevators in service but residents filed complaints anyway. It was wrong — 311's elevator complaints are almost entirely DOB and HPD building elevators, with no transit channel at all. We tore it out.
We found a census tract showing 66.7% of residents with an ambulatory difficulty. Also wrong — a 405-person tract with a group-quarters facility skewing the denominator. We built margin-of-error suppression so numbers like that never reach a user.
We reached for a NYC Parks accessibility dataset that turned out to be three columns last updated in 2013. And a Summer Meals feed that duplicated every site across two program cycles, so 507 records were really about 254 places.
Four striking findings, all artifacts, all caught before they shipped. That discipline became the product.
Accomplishments that we're proud of
An app that is honest about what it doesn't know. Every accessibility claim carries its provenance, nothing renders green without human verification, and the app says plainly that it cannot verify ingredients or allergens rather than guessing.
Eleven data sources joined into one answer, five languages, a working fallback when the network fails.
And two findings we're handing back to the commons: 15 of 40 sites sit in tracts where more residents have trouble walking than the citywide median, four of those more than three-quarters of a mile from an accessible station. Only 8 of 40 have a bench within 50 meters of the station — a program built for seniors and disabled New Yorkers, with nowhere to sit at four-fifths of these sites.
What we learned
NYC pools serve meals. That was the surprise that reframed the project. The Parks pool facilities are exactly the sites with weekend hours, which means they're where a working parent can actually go — and none of them are labeled in a way that tells you food is there.
311 complaints can be turned into street-safety data. They're filed as gripes and stored as case records, but read as a corridor, they tell you where sidewalks are broken, where curb cuts are missing, and where buildings have one elevator and no backup. Under those conditions, the trip we're mapping never starts.
Public data goes stale quietly. Nobody marks it. You have to check.
What's next for Reachable NYC
The verification layer. The transit half of this problem is solvable with public feeds. The destination half — is the entrance step-free, is the door wide enough, is the ramp blocked today — has no dataset anywhere. It has to be built by people, verified with a date attached, and re-verified on a schedule.
Next after that: pedestrian routing that accounts for curb cuts and sidewalk obstructions, real-time closures from Parks and the school system, and expansion past summer meals to pantries, senior centers, and clinics. Our FUTURE.md lists the datasets already identified and not yet wired.
The long version is a city where nobody has to guess whether they can get to the help that's waiting for them.
Built With
- anthropic-claude
- census-api
- css
- geojson
- html
- javascript
- leaflet.js
- mta-api
- node.js
- nyc-open-data
- openstreetmap
- socrata
- usda-api
- vercel
Log in or sign up for Devpost to join the conversation.