Status: early. This is groundwork for Report It, which is still at the concept stage. Nothing here should be read as a finished product decision — it's the reasoning we're working from.

The starting question

Before building anything, we wanted to understand: when a resident notices a pothole, broken streetlight, or unsafe crossing, what actually happens when they try to report it today? Where does that process break down?

What we looked at

  • Public-facing 311-style reporting portals in a handful of mid-sized cities
  • Existing open-source civic reporting projects and why some appear inactive
  • Informal reporting that happens instead — neighborhood social apps, local Facebook groups, direct calls to a council member's office

What stood out

The intake form usually isn't the hard part

Most cities we looked at do have some kind of online reporting form. The friction wasn't primarily "there's no way to report this" — it was more often that the form was hard to find, wasn't mobile-friendly, or required information (like a precise cross-street or a case category) that residents don't naturally have on hand.

The bigger gap is after submission

The more consistent complaint, informally, was silence after reporting — no confirmation, no status, no sense of whether anything happened. Several existing open-source civic tech projects seem to have focused heavily on the submission side and less on closing that status-visibility gap, which may be part of why some haven't sustained active users.

Data access varies enormously by city

Some municipalities expose an open API or structured email intake for these reports; many don't, and getting a report into their system means duplicating their exact form fields, or it doesn't reach anyone at all. This is probably the single biggest constraint on what a v1 of Report It can realistically promise.

What this means for scope

Given the intake-side friction is real but secondary, and the status-visibility gap seems under-addressed, an early version should probably prioritize: (1) a fast, mobile-first report flow, and (2) a simple, honest status view — even if that status view sometimes just says "submitted, no update from the city yet" rather than pretending to track something the city itself doesn't expose.

It also means picking a single pilot city with usable intake (API or structured email) before writing the general version — trying to be city-agnostic from day one would mean building against an interface that doesn't reliably exist.

The lesson so far: the reporting form is rarely the actual bottleneck. What happens — or doesn't — after submission is.

This is still shaping up. If you've worked on civic reporting tools, or you know a city with a genuinely good public works API, we'd like to hear from you.