If you have ever inherited a stormwater program built on a spreadsheet stack that one person understood and nobody else can read, you know the configurability problem. The spreadsheet became “configurable” because the original author kept adding columns and tabs until the workbook matched the program. Six staff transitions later, nobody can explain why column AG exists.
The software that replaces the spreadsheet has the opposite problem. Most SaaS products are rigid where the municipality needs flexibility (terminology, BMP types, source-control categories, inspection field labels), and flexible where the municipality needs guardrails (anything that should be the same across years, across staff, across audits).
This post walks through what a configurable stormwater inspection workflow should actually let a municipality change, and what it should keep stable.
The spreadsheet did the wrong kind of customization
A spreadsheet stack is infinitely customizable at the wrong layer. Any staff member can add a column, rename a sheet, change a formula, or split a tab. That sounds like freedom. In practice it means there is no shared vocabulary across years, no enforcement of which fields are required, and no audit trail when a field changed meaning.
When the state-agency reviewer asks “how were these counts derived,” the answer is whatever the spreadsheet says today, not what it said when the counts were originally logged.
The rigid SaaS does the wrong kind of guardrail
The rigid product solves the audit problem by locking everything. Inspection forms are hard-coded. BMP type dropdowns are vendor-controlled. Workflow steps are baked in. The product is “audit-defensible” in the sense that nobody can break it, including the program that needs to make it match local language.
The result is a workspace that does not look like the program. Inspectors get confused because the field labels do not match their training. Coordinators write workarounds in free-text notes. Audit records technically exist, but they do not say what the program actually does.
Configurable in the right places, structured in the right places
A working pattern: ship the platform stormwater-ready, with structured modules for inspections, IDDE, source control, construction, O&M, and reporting. Let the municipality configure the parts that should be local. Keep the parts that should not change locked under platform structure.
Configurable in the workspace:
- Module toggles. A city without a public-education program should not see MCM 1 modules on its dashboard. A team without source control should not see source control inspections in My Work.
- Terminology. “Catch basin” or “drainage structure” or “inlet”: the program already has a word. The workspace should use it.
- Inspection fields. Which fields show, which are required, what the field labels say. A construction site inspection in a coastal program asks different questions than the same inspection inland.
- Dropdown values. BMP types vary by region. Finding categories vary by program. Enforcement action types vary by ordinance. The dropdowns should match what the inspector actually picks.
- Workflow timing. The cadence rule that says “re-inspect within 48 hours of a deficient finding” should be a configurable value, not a vendor decision.
- Site, contact, and asset inventories. Imported from standard formats so the workspace shapes around the city’s reality, not a generic example.
Structured under platform control:
- Tenant isolation. Each municipality’s records live in its own tenant. No customer can configure their way into another customer’s data.
- Audit trails on key records. Create, edit, and override events are timestamped and attributed. Configuration cannot disable the audit log.
- Permit framework alignment. The MCMs of a Phase II permit are the MCMs. The product carries them as structural concepts, not as relabel-able dropdowns.
- Role-based access. Roles exist at the platform layer. Programs configure who is in which role, not what the roles can do.
The honest version: configuration is what makes the workspace match how the program runs. Structure is what makes the records hold up through an audit.
What configuration is not
A few clarifications, because vendor marketing on this is often misleading.
Configuration is not custom development. Module toggles, terminology, and inspection fields are part of the platform. Building a fully custom module (a new workflow concept that does not exist yet) is custom-module work, scoped separately. NPDESTracker does not promise unlimited free custom development.
Configuration is not arbitrary database editing. Customers do not write SQL against their tenant. They configure structured options the platform exposes.
Configuration is not a guarantee of compliance. The configurable workspace is a better tool than the spreadsheet or the rigid SaaS, but compliance still depends on the program doing the work. The product does not auto-submit reports to any state agency.
What a municipality should ask a stormwater software vendor
A few questions worth asking on a sales call:
- Can our inspection forms use our terminology? The answer should be yes, through configuration. Not “we will write you a custom form.”
- Can we turn off modules we do not use? The answer should be yes. A program without public participation should not see MCM 2 surfaces.
- Can we edit dropdown values without filing a support ticket? The answer should be yes for normal fields like BMP types and finding categories.
- What is the audit trail when we change a configuration? A well-built configurable workspace logs configuration changes the same way it logs record changes.
- What is custom-module work, and what is configuration? A vendor that cannot draw a clear line between configurable-included work and custom-quoted work is a vendor that will surprise you with a bill.
How NPDESTracker handles this
NPDESTracker ships stormwater-ready and lets the municipality configure modules, terminology, inspection fields, dropdown values, and workflow timing as part of every annual tier. The configuration happens in the workspace, not through a custom code build. Larger custom-module development (a workflow concept that does not exist yet) is scoped separately during the kickoff conversation.
The inspection-focused landing pages cover specific slices: stormwater inspection software for the cluster overview, MS4 inspection software for the Phase II permit framing, and digital stormwater inspections for the field-workflow angle.
Try the demo to see how the workspace looks on sample data. The 60-day Guided Pilot is the path most cities take when they want to test the workflow on their own program, with the workspace configured around their permit and inventory. Full pricing is on the pricing page.