What could permitting learn from Agile?
From batch reviews to real-time feedback, this post explores how Agile principles and AI can reshape permitting workflows and eliminate the delays built into today’s systems.
Safouen Rabah
Founder and CEO at Govstream.ai
Posted on
Table of contents
At its best, permitting is a partnership. A homeowner gets clear guidance before investing in design. An architect submits a complete, compliant application the first time. A reviewer opens a well-organized file and focuses entirely on the substantive questions that require professional judgment. A permit issues in weeks, not months.
That version of permitting is not a fantasy. It is an engineering problem. The software industry spent thirty years working under a model that produced many of the same frustrations permitting faces today: late feedback, expensive rework, and timelines that compounded in the wrong direction. They called that model Waterfall. The approach they built to replace it, Agile, is twenty-five years old, battle-tested, and full of lessons that translate directly to how permitting works.
At its best, permitting is a partnership. A homeowner gets clear guidance before investing in design. An architect submits a complete, compliant application the first time. A reviewer opens a well-organized file and focuses entirely on the substantive questions that require professional judgment. A permit issues in weeks, not months.
That version of permitting is not a fantasy. It is an engineering problem. The software industry spent thirty years working under a model that produced many of the same frustrations permitting faces today: late feedback, expensive rework, and timelines that compounded in the wrong direction. They called that model Waterfall. The approach they built to replace it, Agile, is twenty-five years old, battle-tested, and full of lessons that translate directly to how permitting works.
Where Waterfall came from
Waterfall was not invented by software engineers. It was borrowed from industrial project management, the same linear, phase-gated logic that governed large-scale manufacturing and construction for decades. The idea was simple: lock requirements upfront, execute each phase in sequence, move forward only after each gate is approved. Do not start building until the design is complete. Do not test until the build is done.
For physical assembly lines, some of that logic holds. You cannot install a windshield before the car body exists. So the process makes sense for building a structure in the physical world. The same is not true for permitting it. That process takes place in the virtual world, and it is 100% knowledge work
For knowledge work, where requirements are complex, context-specific, and discovered as you go, waterfall is highly inefficient and fraught with risk. Software teams learned this the hard way over thirty years. Projects delivered months or years late. Products built to spec but wrong. Defects discovered only after the full build was complete, requiring the full build to be redone. The cost of being wrong compounded the further downstream you were when you found out.
By 2001, a group of engineers had had enough. They gathered in Snowbird, Utah, and wrote the Agile Manifesto: four values and twelve principles for how complex, knowledge-intensive work actually moves. Continuous feedback over batch reviews. Working output over comprehensive documentation. Customer collaboration over formal specification. Responding to what you learn rather than following a plan you made before you knew anything.
It reshaped how the world builds software.
Permitting systems never got the memo.
Where Waterfall came from
Waterfall was not invented by software engineers. It was borrowed from industrial project management, the same linear, phase-gated logic that governed large-scale manufacturing and construction for decades. The idea was simple: lock requirements upfront, execute each phase in sequence, move forward only after each gate is approved. Do not start building until the design is complete. Do not test until the build is done.
For physical assembly lines, some of that logic holds. You cannot install a windshield before the car body exists. So the process makes sense for building a structure in the physical world. The same is not true for permitting it. That process takes place in the virtual world, and it is 100% knowledge work
For knowledge work, where requirements are complex, context-specific, and discovered as you go, waterfall is highly inefficient and fraught with risk. Software teams learned this the hard way over thirty years. Projects delivered months or years late. Products built to spec but wrong. Defects discovered only after the full build was complete, requiring the full build to be redone. The cost of being wrong compounded the further downstream you were when you found out.
By 2001, a group of engineers had had enough. They gathered in Snowbird, Utah, and wrote the Agile Manifesto: four values and twelve principles for how complex, knowledge-intensive work actually moves. Continuous feedback over batch reviews. Working output over comprehensive documentation. Customer collaboration over formal specification. Responding to what you learn rather than following a plan you made before you knew anything.
It reshaped how the world builds software.
Permitting systems never got the memo.
The Waterfall permitting process
Walk through a typical residential permit and the parallels are difficult to ignore.
An applicant assembles a complete plan set based on their best guess at what is required. They submit it in full. Then they wait.
The first wall is completeness. Before a technical reviewer ever opens the file, the application must clear an administrative intake check. Nationally, thirty-three percent of site plans are denied at the administrative phase alone — before anyone with subject-matter expertise has touched the file. IIn many jurisdictions, between fifty and seventy percent of applications arrive incomplete at intake. The defects were knowable before submission. The system had no mechanism to surface them first.
The second wall is the correction cycle. Once an application clears intake and enters technical review, it encounters the same batch feedback problem that Waterfall produces in software. The application enters a queue. Weeks pass. A correction letter arrives as a batch PDF listing every issue found across every discipline. The applicant revises the entire plan set and resubmits. Three to four correction cycles are standard for a typical residential permit. Up to seven for complex cases. Each cycle adds two to four weeks.
Every month of delay adds roughly $4,800 in carrying costs for a low-cost housing unit. In severe cases, a 143-day delay translates to more than $157,000 in unexpected expenses. In major metros, the average permitting timeline runs to 22 months.
This is not a failure of effort or intent. It is a failure of design. The workflow was built on Waterfall logic: submit everything, wait for the gate, receive batch feedback, repeat. Nobody chose this consciously. It is just how the process was architected. And like Waterfall in software, it creates the same predictable problems: wait states at every handoff, rework paid at full price, and risks that surface only after the investment has already been made.
Agile offers a different architecture. Here is what applying it to permitting could look like in 4 practical steps, and one forward-looking leap we can all take in the future.
The Waterfall permitting process
Walk through a typical residential permit and the parallels are difficult to ignore.
An applicant assembles a complete plan set based on their best guess at what is required. They submit it in full. Then they wait.
The first wall is completeness. Before a technical reviewer ever opens the file, the application must clear an administrative intake check. Nationally, thirty-three percent of site plans are denied at the administrative phase alone — before anyone with subject-matter expertise has touched the file. IIn many jurisdictions, between fifty and seventy percent of applications arrive incomplete at intake. The defects were knowable before submission. The system had no mechanism to surface them first.
The second wall is the correction cycle. Once an application clears intake and enters technical review, it encounters the same batch feedback problem that Waterfall produces in software. The application enters a queue. Weeks pass. A correction letter arrives as a batch PDF listing every issue found across every discipline. The applicant revises the entire plan set and resubmits. Three to four correction cycles are standard for a typical residential permit. Up to seven for complex cases. Each cycle adds two to four weeks.
Every month of delay adds roughly $4,800 in carrying costs for a low-cost housing unit. In severe cases, a 143-day delay translates to more than $157,000 in unexpected expenses. In major metros, the average permitting timeline runs to 22 months.
This is not a failure of effort or intent. It is a failure of design. The workflow was built on Waterfall logic: submit everything, wait for the gate, receive batch feedback, repeat. Nobody chose this consciously. It is just how the process was architected. And like Waterfall in software, it creates the same predictable problems: wait states at every handoff, rework paid at full price, and risks that surface only after the investment has already been made.
Agile offers a different architecture. Here is what applying it to permitting could look like in 4 practical steps, and one forward-looking leap we can all take in the future.
1- Restore the conversation the portal took away
One of Agile's core values is individuals and interactions over processes and tools. This sounds abstract until you see what it produced in practice: the daily standup.
The standup is not a meeting. It is a fifteen-minute pulse check for engineers, product managers, and designers to surface blockers in real time, before they compound. Problems get aired immediately. They do not accumulate until the next phase review. The rhythm itself is the point: frequent, low-friction communication keeps work moving.
Before digitization, permitting worked something like this. A homeowner walked into City Hall, sat across from someone who knew the codes, and left with a clear plan forward. The process was imperfect and slow, but it was guided and human. The expertise was in the room.
Decades of digitization replaced that conversation with portals, rigid forms, and silent document drops. We ceded the human language of collaboration to machines that imposed system-level constraints. Your PDFs must be in exactly this format. Some systems even require the applicant to rename their files so the ‘system’ can accept them. The human complexity of permitting never disappeared. Zoning overlays, critical area triggers, ADU rules, parcel-specific requirements: all of it is still there. The guidance is just buried in PDF guides and web pages that no applicant has time to navigate, and that no staff member has time to walk everyone through individually. Today, 66% of applicants report profound dissatisfaction with the permitting process. That is not just a technology failure. It is also a communication failure.
The Agile answer is to make communication a design principle, not a phase gate. That is what AI makes possible at scale. A homeowner with a question gets a real answer, grounded in their specific parcel, with the relevant code section cited, at any hour, through any channel they already use to reach the city. Staff get a draft response ready to review and send in under a minute. The conversation is restored. The bottleneck is not.
2- Pull the risk forward before the architect sends the invoice
Agile teams test early. They run automated checks as code is written, not after the product ships. They validate the risky assumptions first, before committing to full build. The reason is straightforward: defects caught early are cheap. Defects caught late are not.
Permitting catches its defects late. An architect spends weeks drawing a complete plan set. Submits. Finds out the parcel sits in a historic district that requires additional design review. Or that a steep slope triggers a geotechnical report that was not budgeted. Or that a critical area overlay changes the buildable envelope entirely.
That information was in the public record before the first drawing was made. The system had no mechanism to surface it before the work began. The defect was discoverable at the start. The system waited until after thousands of dollars in professional fees were spent to raise it.
The Agile fix is to move the risk check to the front of the process — before the design begins, not after it is submitted. An applicant enters an address. Before the architect opens the design file, every constraint that applies to that specific parcel is on the screen: critical area overlays, historic district designations, slope triggers, flood zone classifications, ADU eligibility. The architect designs to the constraints from day one. The constraints were always there. Now they arrive before the invoice does.
AI makes this possible at the parcel level. The information exists in GIS records, zoning databases, and municipal code — distributed across systems that no single applicant can reasonably navigate. AI reads across those sources simultaneously, resolves them to a specific address, and returns a complete constraint picture in seconds. Not as a substitute for professional judgment. As the briefing that makes professional judgment more effective.
Test early. Fix it while it’s inexpensive to do so.
1- Restore the conversation the portal took away
One of Agile's core values is individuals and interactions over processes and tools. This sounds abstract until you see what it produced in practice: the daily standup.
The standup is not a meeting. It is a fifteen-minute pulse check for engineers, product managers, and designers to surface blockers in real time, before they compound. Problems get aired immediately. They do not accumulate until the next phase review. The rhythm itself is the point: frequent, low-friction communication keeps work moving.
Before digitization, permitting worked something like this. A homeowner walked into City Hall, sat across from someone who knew the codes, and left with a clear plan forward. The process was imperfect and slow, but it was guided and human. The expertise was in the room.
Decades of digitization replaced that conversation with portals, rigid forms, and silent document drops. We ceded the human language of collaboration to machines that imposed system-level constraints. Your PDFs must be in exactly this format. Some systems even require the applicant to rename their files so the ‘system’ can accept them. The human complexity of permitting never disappeared. Zoning overlays, critical area triggers, ADU rules, parcel-specific requirements: all of it is still there. The guidance is just buried in PDF guides and web pages that no applicant has time to navigate, and that no staff member has time to walk everyone through individually. Today, 66% of applicants report profound dissatisfaction with the permitting process. That is not just a technology failure. It is also a communication failure.
The Agile answer is to make communication a design principle, not a phase gate. That is what AI makes possible at scale. A homeowner with a question gets a real answer, grounded in their specific parcel, with the relevant code section cited, at any hour, through any channel they already use to reach the city. Staff get a draft response ready to review and send in under a minute. The conversation is restored. The bottleneck is not.
2- Pull the risk forward before the architect sends the invoice
Agile teams test early. They run automated checks as code is written, not after the product ships. They validate the risky assumptions first, before committing to full build. The reason is straightforward: defects caught early are cheap. Defects caught late are not.
Permitting catches its defects late. An architect spends weeks drawing a complete plan set. Submits. Finds out the parcel sits in a historic district that requires additional design review. Or that a steep slope triggers a geotechnical report that was not budgeted. Or that a critical area overlay changes the buildable envelope entirely.
That information was in the public record before the first drawing was made. The system had no mechanism to surface it before the work began. The defect was discoverable at the start. The system waited until after thousands of dollars in professional fees were spent to raise it.
The Agile fix is to move the risk check to the front of the process — before the design begins, not after it is submitted. An applicant enters an address. Before the architect opens the design file, every constraint that applies to that specific parcel is on the screen: critical area overlays, historic district designations, slope triggers, flood zone classifications, ADU eligibility. The architect designs to the constraints from day one. The constraints were always there. Now they arrive before the invoice does.
AI makes this possible at the parcel level. The information exists in GIS records, zoning databases, and municipal code — distributed across systems that no single applicant can reasonably navigate. AI reads across those sources simultaneously, resolves them to a specific address, and returns a complete constraint picture in seconds. Not as a substitute for professional judgment. As the briefing that makes professional judgment more effective.
Test early. Fix it while it’s inexpensive to do so.
3- A correction letter is batch feedback. Agile would never ship it that way
Continuous integration is one of the foundational practices of modern software development. Every code commit triggers automated checks. Problems surface immediately, in context, while the work is still fresh. The developer sees the issue as it is introduced, not three weeks later during a formal review.
The correction letter is the opposite. All feedback accumulates during the review cycle and arrives in one batch, as a PDF, weeks after submission. The applicant must revise the full plan set and resubmit. The revised application then joins the back of the queue and the cycle runs again.
Those three to four cycles are not just a time problem. The batch format compounds the delay in a specific way: one complex structural issue holds up three simple formatting corrections that could have been resolved in an afternoon. Everything waits for everything else, because the feedback model treats the application as a single indivisible unit.
There is a better question to ask: why does any feedback have to wait? Why can't an applicant start addressing issues as they are identified, rather than receiving them all at once at the end of a full review cycle?
It does not have to work this way. AI can flag completeness issues before an application enters the review queue at all. And when an application does enter review, corrections can become a live, structured checklist rather than a batch PDF. Each issue is trackable and addressable the moment it is raised. When a fix comes in, the reviewer sees it immediately. Not at the next formal resubmission.
Batch feedback is a design choice. It can be redesigned.
4- Wait states are the silent killer
Agile teams do not work through their backlog in order of arrival. Sprint planning exists to assess the work before scheduling it. A two-point bug fix does not wait behind a forty-point feature build. High-value, low-effort items are identified and moved accordingly. The team knows what is in the queue and routes effort to match.
Permitting queues are almost universally first-in, first-out. Work enters in the order it arrives and exits in the same order, regardless of what it actually contains.
Here is what that means in practice. A builder submits a targeted revision addressing the three specific issues raised in the first correction letter. The revisions are precise. Verifying them would take fifteen minutes. That resubmission sits at the bottom of the queue behind new applications, because no one has opened it, no one knows what is in it, and the system treats it identically to a complex new submission that needs days of review.
In any jurisdiction with published permit data, the pattern is the same: the gap between median and average processing times is large. Most permits are routine. A small number are complex. FIFO forces them to share the same queue, and the outliers set the pace for everyone. The system has no mechanism to tell them apart at intake.
In lean manufacturing, studies consistently find that 80 to 90 percent of total process lead time is queue time, not work time. The work is not the constraint. The wait is. Permitting is no different: a targeted resubmission takes fifteen minutes to verify and three weeks to reach a reviewer. Not because the review is difficult. Because the queue treats it identically to everything else.
AI changes that. By reading a resubmission before it enters the queue, identifying what changed relative to the prior version, and flagging targeted revisions for expedited handling, the system gives reviewers exactly the information they need to prioritize intelligently. A fifteen-minute review gets treated like a fifteen-minute review. The queue becomes a managed workflow, not a line.
3- A correction letter is batch feedback. Agile would never ship it that way
Continuous integration is one of the foundational practices of modern software development. Every code commit triggers automated checks. Problems surface immediately, in context, while the work is still fresh. The developer sees the issue as it is introduced, not three weeks later during a formal review.
The correction letter is the opposite. All feedback accumulates during the review cycle and arrives in one batch, as a PDF, weeks after submission. The applicant must revise the full plan set and resubmit. The revised application then joins the back of the queue and the cycle runs again.
Those three to four cycles are not just a time problem. The batch format compounds the delay in a specific way: one complex structural issue holds up three simple formatting corrections that could have been resolved in an afternoon. Everything waits for everything else, because the feedback model treats the application as a single indivisible unit.
There is a better question to ask: why does any feedback have to wait? Why can't an applicant start addressing issues as they are identified, rather than receiving them all at once at the end of a full review cycle?
It does not have to work this way. AI can flag completeness issues before an application enters the review queue at all. And when an application does enter review, corrections can become a live, structured checklist rather than a batch PDF. Each issue is trackable and addressable the moment it is raised. When a fix comes in, the reviewer sees it immediately. Not at the next formal resubmission.
Batch feedback is a design choice. It can be redesigned.
4- Wait states are the silent killer
Agile teams do not work through their backlog in order of arrival. Sprint planning exists to assess the work before scheduling it. A two-point bug fix does not wait behind a forty-point feature build. High-value, low-effort items are identified and moved accordingly. The team knows what is in the queue and routes effort to match.
Permitting queues are almost universally first-in, first-out. Work enters in the order it arrives and exits in the same order, regardless of what it actually contains.
Here is what that means in practice. A builder submits a targeted revision addressing the three specific issues raised in the first correction letter. The revisions are precise. Verifying them would take fifteen minutes. That resubmission sits at the bottom of the queue behind new applications, because no one has opened it, no one knows what is in it, and the system treats it identically to a complex new submission that needs days of review.
In any jurisdiction with published permit data, the pattern is the same: the gap between median and average processing times is large. Most permits are routine. A small number are complex. FIFO forces them to share the same queue, and the outliers set the pace for everyone. The system has no mechanism to tell them apart at intake.
In lean manufacturing, studies consistently find that 80 to 90 percent of total process lead time is queue time, not work time. The work is not the constraint. The wait is. Permitting is no different: a targeted resubmission takes fifteen minutes to verify and three weeks to reach a reviewer. Not because the review is difficult. Because the queue treats it identically to everything else.
AI changes that. By reading a resubmission before it enters the queue, identifying what changed relative to the prior version, and flagging targeted revisions for expedited handling, the system gives reviewers exactly the information they need to prioritize intelligently. A fifteen-minute review gets treated like a fifteen-minute review. The queue becomes a managed workflow, not a line.
5- Future-forward: Validate the concept before you invest in the full build
Agile's most enduring contribution to product thinking is the MVP: build the minimum that tests the core assumption. Get real feedback under real conditions before committing to full execution. The logic runs even deeper in continuous delivery: the feedback loop between writing code and knowing whether it works has compressed from weeks to minutes to seconds. Every line is tested in context, as it is written.
Today, the permitting equivalent of "write code and wait for QA" is still the default.
A homeowner commissions full construction drawings before knowing whether the project is fundamentally permittable. A developer spends on site studies and architectural fees before asking the questions that should come first: can I build this here? What will it trigger? What are the constraints specific to this parcel?
Pre-application conferences exist in many cities, which is great! But they are manual, slow to schedule, and available mainly to those who know to ask for them. For a first-time homeowner or a small contractor, they can be invisible.
The logical endpoint of applying Agile to permitting is more ambitious than a faster pre-application check, or quicker turnaround times during plan reviews. It is regulatory feedback that happens in real time with design. As an architect sets a building footprint, the system checks setbacks. As a floor height is defined, it checks against zoning maximums. As a room count is added, it flags occupancy and egress requirements. Not after submission. Not in a pre-application conference scheduled three weeks out. During the design itself.
This is not science fiction. The regulatory data exists. The design tools exist. AI is what connects them — resolving parcel-specific constraints against design decisions as they are made, flagging issues at the moment they are introduced rather than weeks after they are committed to.
Continuous integration for the built environment. That is the direction this is heading. And it is the ultimate expression of what lean and Agile, applied to permitting, actually look like.
5- Future-forward: Validate the concept before you invest in the full build
Agile's most enduring contribution to product thinking is the MVP: build the minimum that tests the core assumption. Get real feedback under real conditions before committing to full execution. The logic runs even deeper in continuous delivery: the feedback loop between writing code and knowing whether it works has compressed from weeks to minutes to seconds. Every line is tested in context, as it is written.
Today, the permitting equivalent of "write code and wait for QA" is still the default.
A homeowner commissions full construction drawings before knowing whether the project is fundamentally permittable. A developer spends on site studies and architectural fees before asking the questions that should come first: can I build this here? What will it trigger? What are the constraints specific to this parcel?
Pre-application conferences exist in many cities, which is great! But they are manual, slow to schedule, and available mainly to those who know to ask for them. For a first-time homeowner or a small contractor, they can be invisible.
The logical endpoint of applying Agile to permitting is more ambitious than a faster pre-application check, or quicker turnaround times during plan reviews. It is regulatory feedback that happens in real time with design. As an architect sets a building footprint, the system checks setbacks. As a floor height is defined, it checks against zoning maximums. As a room count is added, it flags occupancy and egress requirements. Not after submission. Not in a pre-application conference scheduled three weeks out. During the design itself.
This is not science fiction. The regulatory data exists. The design tools exist. AI is what connects them — resolving parcel-specific constraints against design decisions as they are made, flagging issues at the moment they are introduced rather than weeks after they are committed to.
Continuous integration for the built environment. That is the direction this is heading. And it is the ultimate expression of what lean and Agile, applied to permitting, actually look like.
What this costs when we don't fix it
A 25% reduction in permitting delay produces a 33% increase in total housing production. Not through zoning reform. Not through budget increases. Not through hiring more staff into a market where 71% of local governments report engineering and technical positions are hard to fill. Just by running a process designed this century.
Every month of permitting delay adds $4,800 in carrying costs that gets passed directly to the buyer or renter. In gateway cities, only 5% of new production is the missing-middle housing most communities need most, largely because the complexity and unpredictability of the permitting process makes small projects economically unviable. Complex permitting kills small projects first. It prices out the homeowner adding an ADU, the contractor building a duplex, the small developer trying to add six units to an infill lot.
These are not abstract efficiency numbers. They are housing units. They are families that are priced out of their starter home.
What this costs when we don't fix it
A 25% reduction in permitting delay produces a 33% increase in total housing production. Not through zoning reform. Not through budget increases. Not through hiring more staff into a market where 71% of local governments report engineering and technical positions are hard to fill. Just by running a process designed this century.
Every month of permitting delay adds $4,800 in carrying costs that gets passed directly to the buyer or renter. In gateway cities, only 5% of new production is the missing-middle housing most communities need most, largely because the complexity and unpredictability of the permitting process makes small projects economically unviable. Complex permitting kills small projects first. It prices out the homeowner adding an ADU, the contractor building a duplex, the small developer trying to add six units to an infill lot.
These are not abstract efficiency numbers. They are housing units. They are families that are priced out of their starter home.
What Agile actually means for permitting
The five principles above are not aspirational. They are operational, and they are available now. Surface risks before design begins. Close feedback loops in real time. Route work by complexity, not by arrival order. Restore the guided, responsive conversation that the portal replaced. And where possible, pull feasibility into the earliest stage of the design process, so the investment is made with full information.
Permitting is one of the few remaining workflows where knowledge-intensive, expert-dependent work still runs on a Waterfall model. That is not inherent to government. It is a design inheritance. And design can change.
The housing is waiting.
______________________________________________________________
Govstream.ai builds intelligent AI-powered permitting workflows for cities and counties. Our platform, Permit Guide, Application Assistant, and Review Assistant, brings continuous feedback, intelligent routing, and real-time decision support to every stage of the permitting process to support staff and guide builders.
What Agile actually means for permitting
The five principles above are not aspirational. They are operational, and they are available now. Surface risks before design begins. Close feedback loops in real time. Route work by complexity, not by arrival order. Restore the guided, responsive conversation that the portal replaced. And where possible, pull feasibility into the earliest stage of the design process, so the investment is made with full information.
Permitting is one of the few remaining workflows where knowledge-intensive, expert-dependent work still runs on a Waterfall model. That is not inherent to government. It is a design inheritance. And design can change.
The housing is waiting.
______________________________________________________________
Govstream.ai builds intelligent AI-powered permitting workflows for cities and counties. Our platform, Permit Guide, Application Assistant, and Review Assistant, brings continuous feedback, intelligent routing, and real-time decision support to every stage of the permitting process to support staff and guide builders.
Modern permitting
for growing cities
Modern permitting for growing cities
Govstream.ai helps cities modernize permitting, improve efficiency, and support sustainable growth.
Govstream.ai helps cities modernize permitting, improve efficiency, and support sustainable growth.
