NPDESTracker

What stormwater inspectors actually need from inspection software

A practical look at what a working stormwater inspector needs from inspection software: forms that know the inspection kind, photos and GPS on the record, follow-up tasks, field markups, and exports that survive an audit.

Published May 21, 2026

If you have ever inspected an outfall in February and tried to remember three days later whether you wrote it down, you know what stormwater inspectors actually need from inspection software. It is not a feature list. It is whether the record survives the drive back to the office.

This post is for the inspector in the truck, the coordinator who manages the program, and the supervisor who has to defend the records when the state agency shows up. The angle is what works in the field, not what looks good in a demo.

A form that knows what kind of inspection it is

Generic inspection apps flatten everything into “did you find a problem? yes or no.” That is not how stormwater inspections work. A construction site inspection cares about silt fence and concrete washout. A vault inspection cares about whether the sump is half full of grit. A bioswale inspection cares about ponding depth and vegetation health. An IDDE field visit cares about indicator panel results.

The inspection record needs a structured form per kind. The right fields, in the right order, with the right vocabulary. If the form asks “did you find a problem?” the inspector ends up writing the actual finding in a free-text note that future auditors cannot search.

Photos and GPS on the record, not in a folder

Photos in a separate folder on a shared drive go missing. Not always, but often enough that programs end up with inspections that say “see photo” and a photo folder that was reorganized in 2024.

Photos belong on the inspection record, with GPS pinned at the moment of capture. The location of the photo is the location of the inspection. The next auditor can open the record and see what was seen, where it was seen, on what date.

Follow-up tasks attached to the source inspection

A finding that does not turn into a task is a finding that gets forgotten. The work the inspector did finding the problem is wasted if the closure never lands on the same record.

A practical inspection workflow opens a task when the finding is deficient. The task carries a due date, an assignee, and a place for closure evidence. The next inspector who walks the site sees the open finding before they get out of the truck. The supervisor sees overdue tasks across the program before the year runs out.

Field markups as a separate exportable layer

Field inspectors notice things the authoritative GIS does not know yet. A catch basin that the city’s storm drain network shows in one location but is actually fifteen feet north. A pipe alignment that no longer matches reality. A pond that grew over the past decade.

Writing those observations into the authoritative GIS in the field is a bad idea. The city’s source of truth needs to stay under GIS staff control. But losing the observation is also bad.

The right pattern is a separate exportable layer. The inspector draws the missing catch basin, the pipe of interest, or the field note as a markup on their own layer. The layer exports as GeoJSON to the GIS team, who decide whether and how to merge it into the authoritative source. The inspector’s observation survives without bypassing GIS staff.

Draft notices started from the inspection record

When the inspection finds something that warrants a courtesy notice, a correction request, or an illicit discharge notice, the draft should start from the inspection record. The evidence the notice cites is already attached. The site context is already there. The inspector or coordinator fills in the narrative and copies or downloads the email-ready text.

Notice drafts always support copyable or printable delivery. Direct email delivery, reply capture, and retained correspondence history are deployment-dependent and confirmed during setup; do not assume those capabilities are included unless they are named in the order.

Exports that survive an audit

A state-agency reviewer asking for “every construction inspection on Site 04 between June 2024 and February 2025” should get a clean CSV in two clicks. Not a screenshot. Not a re-typed list. A standard format export that carries the structured fields the records have.

Same for the spatial data. GeoJSON exports cover the inspection record’s coordinates and the field markup layer.

How NPDESTracker lines up

NPDESTracker is built around responsive connected forms per inspection kind, configured file attachments, device-dependent geolocation, follow-up tasks attached to the source inspection, field markups as a separate layer, and supported exports whose formats depend on the selected modules and order form. The broader landing page is stormwater inspection software, and the focused pages cover MS4 inspection software, digital stormwater inspections, IDDE inspection software, source control inspection software, construction stormwater inspection software, and field inspection software for MS4 teams.

The responsive web app can be evaluated on connected phones and tablets. Loading and saving records requires a reliable connection. A production offline mode and native field app are not currently offered; device-dependent photo and GPS behavior should be verified during evaluation.

The public demo provides a read-only Inspections view alongside Dashboard, My Work, Coordinator, Tasks, and Map on fictional data; only Map is interactive. The 60-day Guided Evaluation at $999 is the path for testing connected creation, device behavior, and configured exports on the agency’s own program.

See it run.

Explore Dashboard, My Work, Coordinator, Inspections, Tasks, and Map on fully populated, fictional sample data. Messages & Notices and Annual Reporting are locked. No signup, live municipal data, email delivery, or agency submission. The tour is read-only; only Map is interactive.