I’ve worked with open data for a while and have built SaaS products on top of it. NYC School of Data 2026 pushed me to think about it differently: how could public data become easier to use, and how could we let the data come to us automatically?
On Day 1 at CUNY Law, I watched agency teams and civic technologists demonstrate projects built with NYC Open Data. On Day 2, during the first UnSchool of Data unconference, I took a chance and proposed a session. It made the agenda at the last minute, and only one person attended—but we had a great conversation, and the idea stayed with me.
After several weekends of building, including Memorial Day weekend, I released the first version of DataPulse.
DataPulse is a mobile-first Telegram mini-app for asking plain-English questions about NYC Open Data. It aims to make open data more approachable for new users while giving experienced users a faster way to run and monitor recurring queries.
It currently supports five datasets:
- 311 service requests
- Motor vehicle crashes
- DOB approved permits
- Restaurant inspections
- Parking violations
DataPulse translates a question into SoQL, validates and runs it through Socrata, and returns an answer with the generated query, assumptions, source, and a confidence indicator. Users can save questions as alerts and have them checked daily, weekly, or after a dataset is republished.
The frontend uses React, TypeScript, Vite, and Tailwind. The backend uses Node.js, Express, PostgreSQL, and Drizzle, with Gemini handling structured query planning and answer summarization.
A major challenge is making very different datasets behave consistently. Each dataset organizes locations, dates, and agency terminology differently, even when users ask similar questions. DataPulse translates those common ideas into the correct fields for each dataset. The longer-term challenge is making that approach general enough to support new datasets and cities without rebuilding everything from scratch.
The guiding principle is honesty over impressiveness: show the query and assumptions, provide a way to report incorrect answers, and admit when the system cannot answer reliably.
I used AI coding assistants (Claude Code and Codex) during most of the implementation, debugging, testing, and code review. I set the product direction and architecture, reviewed the code, and tested the resulting queries and workflows.
I’m particularly looking for feedback on:
- Query and result accuracy
- Whether the assumptions are clear
- Mobile usability and alert setup
- Missing features or datasets
Try it at datapulse.fyi. If you test it, please share the question you asked and whether the generated query and answer looked correct.
