Should a City Automate Permitting Intake, or Reduce the Number of Permit Types First?

The question nobody sold you

You have a demo scheduled. The council wants permit times down, the front counter is the most complained-about desk in the building, and three vendors have shown you the same slide: applicants submit online, workflows route automatically, dashboards show where everything sits. It is a good slide. The software probably works.

The question underneath it has not been asked. You are about to pay to digitise a permit taxonomy, and nobody in the room has counted how many permit types are in it or how many of them your city issued last year. Search for the comparison and you will not find it. Every result on page one is a permitting software company answering the half of the question that ends in a purchase order. The other half, whether you have too many permit types to begin with, has nobody selling it, which is exactly why it goes unexamined.

We are not arguing against permitting software. We are arguing about sequence, and sequence is where most of these projects quietly lose their return.

What a permit type actually costs you

A permit type is not a line on a fee schedule. It is a bundle of standing obligations that the organisation carries every year whether or not anyone applies.

Each type has a routing rule, which means a decision about which reviewers see it and in what order. It has a fee line, which means a calculation someone maintains and a council action to change. It has a review checklist, which means a document that drifts out of date between code cycles. It has intake guidance, which means a counter clerk who has to know it exists. And it has a page on your website that someone in communications is responsible for.

Now multiply. A mid-sized city commonly carries somewhere between forty and eighty distinct permit and approval types once you count building, planning, fire, right-of-way, encroachment, special event, and business-adjacent approvals. Nobody designed that number. It accumulated, one ordinance at a time, over thirty years, and every one of those ordinances made sense on the day it passed.

Here is the part that matters for your software decision. Automation does not reduce any of that. It encodes it. A configurable platform will happily hold sixty routing rules, and the implementation invoice will reflect the sixty. Then every code update, every fee change, and every reorganisation has to be made in two places forever: the ordinance and the configuration.

Ask how thin the tail is

Before the demo, run one query against your permitting system. Count applications received by permit type for the last two calendar years, sorted descending.

Almost every jurisdiction that runs this finds the same shape. A small number of types carry nearly all the volume, and a long tail of types were issued fewer than a dozen times each. San Francisco published the extreme version of this when it reported that 94 percent of the building permits it issued in February 2022, 1,716 out of 1,816, went over the counter rather than through full plan review. When the overwhelming majority of your work is one kind of work, the thing you should optimise is obvious, and it is not the tail.

The tail is where the design discussion belongs. For each type issued a handful of times a year, there are only three honest answers. It is genuinely rare and genuinely necessary, so leave it and handle it manually. It duplicates another type closely enough that the two should merge. Or the activity it governs no longer needs a discretionary permit at all, and the right move is to make it ministerial or exempt.

That third answer is not hypothetical, and legislatures are increasingly making it for cities that did not make it themselves. Florida's HB 803, signed in May 2026 and effective that July, requires local governments to exempt work under $7,500 on an owner-occupied single-family dwelling from building permit requirements entirely, with structural, electrical, plumbing, mechanical and gas work carved back out. Whatever you think of the policy, notice the mechanism. The state deleted a slice of permit volume rather than speeding it up. A city that had just finished configuring workflows for that slice paid to automate something that stopped existing.

The failure mode, stated plainly

One vendor says this out loud, to its credit. PermiPro's own material notes that automating the application form while leaving the back end manual moves the bottleneck rather than removing it. That is correct and it is under-appreciated, because the symptom it produces looks like success.

Intake automation reliably improves the first hour of the process. Applications arrive complete, legible, and time-stamped. Counter traffic drops. The metric everyone watches, time to first response, gets better immediately. Meanwhile the actual constraint, which is usually a plans examiner's queue or a concurrence from a department that reviews sequentially rather than in parallel, has not moved at all. You have simply built a faster pipe into the same tank.

San Francisco's site permitting reform is instructive here because it is a city diagnosing itself rather than a vendor diagnosing a market. The changes the project proposed were consolidating two duplicative intake processes into one, replacing sequential agency review with concurrent review, and defining what is and is not reviewed at each stage. Only after those did digital process appear on the list. The software was the fifth item, not the first, and the first four are things no product can do for you.

How to sequence it

The useful frame is not automate versus simplify. It is: which permit types are worth encoding, and what does the encoding have to encode?

Sort your types into three groups. High volume and rule-driven is where automation earns its cost, and it is where the whole business case should be built. High volume and judgment-driven is where automation should handle routing, status and evidence, and stay away from the decision itself. Low volume is where you ask whether the type should exist, and where the answer is usually consolidate, delegate, or leave alone.

Do the sort before you scope the implementation, not after, because the sort changes the scope. This is the same discipline we describe in when AI is the wrong answer to an operations problem: the technology question is downstream of a process question that is cheaper to answer and almost never answered first. It also depends on knowing what your work actually costs you, which is the subject of what a permit application costs a county to process. And if your real complaint is that nobody can see where an application is sitting, read what orchestration means once you stop reading the brochure before you conclude you need a platform.

One more thing about the tail. The types issued twice a year are the ones with the loudest internal defenders, because each is somebody's responsibility and nobody wants to be the person who signed off on removing a control. That is a governance conversation, not an analytical one, and it needs a council or a manager willing to spend a little political capital. The analysis is a Tuesday. The decision is the hard part. You might say the whole exercise hinges on getting the right permission.

Where the article stops

What we cannot tell you from here is which of your types belong in which group. That depends on your volume distribution, which departments hold a concurrence and whether they exercise it, what your code actually requires versus what practice has added, and how much of your tail is protected by an ordinance rather than by habit. Those answers come from your own application data and about two weeks of sitting with the people who run the counter and the plan check queue.

If you are being quoted for permitting software this quarter and nobody has counted your permit types, talk to us before you sign. We will run the volume distribution, sort your types into the three groups, tell you which ones to consolidate or retire before implementation, and give you a scope that encodes the process you want rather than the one you have.