Post-Issuance Inspection Workflows
How I designed inspection scheduling and management for PermitFlow, extending the platform beyond permit issuance through project closure
PermitFlow's core product ended at permit issuance, but most construction projects require multiple inspections before permits can be legally closed. Customers were creating workarounds—fake applications and spreadsheets—to track post-issuance work. This created incomplete data and made reporting impossible. I designed an inspection system that extended the application lifecycle through close-out. I worked with engineering to model inspections as first-class entities and built workspace-level configurability to handle wildly different customer workflows.
The system successfully migrated 7+ customers including Fitch Electric, RBA, Service Experts, and PJ Fitzpatrick. It enabled complete lifecycle tracking from application through close-out and supported diverse workflows from information-only to full inspection management through a single configurable system.
The Problem
The Product Ended at Permit Issuance
PermitFlow managed the permit application process from creation through issuance, but for most construction projects, getting a permit issued is only the beginning. Projects require multiple inspections before permits can be legally closed. Customers were creating workarounds to track post-issuance workflows, leading to incomplete data and impossible reporting.
Customers created fake applications or freeform tasks to track inspections, leading to incorrect data models and poor reporting
Customer workflows varied dramatically—some needed only information, others wanted coordination support, and some required full inspection management
Most jurisdictions require passing inspections before permits expire, but there was no system to track this, creating risk of fines and legal issues
Customers like RBA, Service Experts, and PJ Fitzpatrick lacked visibility into post-issuance progress and upcoming deadlines
Designing for Extreme Workflow Variation
Customer interviews revealed a wide spectrum of needs: some just wanted visibility into inspection status, others needed coordination support, and some required full management with scheduling and follow-up. A one-size-fits-all approach wouldn't work, but I also couldn't build separate features for each customer segment.
I worked with engineering to decide on a key architectural choice: treating inspections as first-class entities with their own object model rather than forcing them into the existing application structure. This kept the data model clean and enabled proper reporting. I also pushed for workspace-level configurability so we could serve different customer needs without building separate features for each segment.
The Inspection System
The inspection system extended the application timeline to Created → Issued → Inspections → Closed Out. Once a permit was issued, a dedicated "Inspections" view unlocked, pre-populated with inspections from municipal research or addable on the fly. The view showed expected inspections with status tracking, scheduling dates, contact information, and notes. Users could reorder inspections, upload documentation for passes or failures, and see clear visual indicators for what needed attention.
Project Overview & Public View
New tabs in the project overview table ("Not scheduled," "Scheduled," "Failed," "Closed out") made it trivial to see which projects needed attention. A public application view let homeowners and contractors see inspection status and mark inspections as "Ready" without logging in, eliminating constant back-and-forth communication.
Workspace-Level Configuration
A workspace-level inspections view provided a table of all inspections across projects with filtering and grouping, giving operations teams visibility into workload and bottlenecks. The workspace settings system made everything adaptable—teams could enable inspections selectively, configure scheduling responsibility, and determine whether completion was required for sign-off. This flexibility let us serve wildly different customer needs with a single system.
Reflections
This project taught me the importance of designing for configurability without creating complexity. The workspace settings system was critical—it let us build one feature that served many different use cases rather than building separate features for each customer segment.
The decision to model inspections as first-class objects rather than extending applications paid off. It kept the data model clean, enabled proper reporting, and made the feature understandable to users. The alternative, jamming inspections into the existing application structure, would have created technical debt and confused users.
If I could do it again, I'd involve more customers earlier in the design process. We had strong hypotheses about workflow variation, but actually seeing how different contractors coordinated inspections would have surfaced edge cases sooner. The pilot migrations validated our approach, but earlier customer research would have reduced iteration cycles.