All Things RE: Development, Issue 003

RE: Building the Case, Issue 002

Welcome back to All Things RE: Development. Most issues break down a policy or program change against a real project. This one's about the tools underneath the process itself — what's actually changed in how design and construction teams share data, and why permitting still hasn't caught up to it.


Design and construction spent the last several years solving a problem permitting hasn't touched yet: getting everyone on a project — architect, contractor, subs, owner — working off the same live record instead of a folder each of them maintains separately. The industry has a name for that shift now: Connected Construction, the idea that concept, design, construction, and operations should run on one continuous thread instead of four separate handoffs. Autodesk and Procore have both rebuilt their platforms around it, and it's already changing how projects get built.

Permitting sits outside that shift, and not for lack of anyone trying. Government agencies have spent real money modernizing their own software — new platforms, new logins, in some cases entire jurisdictions consolidating onto the same system. Permitting-adjacent tech companies have raised money marketing themselves as the layer that finally automates the process. Neither one, on its own, has actually pulled permitting into the Connected Construction era. That's the gap we built justPermits to close — treating permitting as a connected component of the project instead of the isolated silo it's traditionally been run as. This issue looks at why that gap still exists everywhere else, then shows what actually closing it looks like on a real project.

RE: Everyone Got a Login, Nobody Got Faster

  • The Experiment. One of the most common fixes proposed for permitting's fragmentation is simple on paper: put every department on the same software, and the process becomes consistent. Los Angeles County actually tested that idea. Starting in 2016, it rolled out Tyler Technologies' EnerGov platform as EPIC-LA across six departments — Regional Planning, Public Works, Parks and Recreation, Fire, Public Health, and more. That's genuine, county-wide, cross-department consolidation, not one division buying software on its own. And in our own experience working projects through it, the fix didn't hold: getting a permit through the County hasn't meaningfully changed. Review timeframes haven't shortened in any way you'd notice on the ground, and applicants and expediters alike still have to learn a real, specific set of requirements just to operate inside the platform correctly — a learning curve that replaced one set of friction with another instead of removing it. A shared system didn't erase the underlying process. It just gave the same process a shared login.

  • Same City, Two Eras. Sometimes it's stranger than that. We've worked with jurisdictions where the application itself comes in through Accela — a genuinely modern front door — and the moment it reaches actual plan check, it gets handed off to ProjectDox, a far older, far less intuitive system that nobody would call modern by comparison. Same project, same city, two completely different eras of software, and the applicant has to learn both.

Architect, Contractor, Engineer, Owner, Expeditor, and subs all working on a connected platform.
  • To Be Fair. This isn't proof that permitting software can't work. Clariti — a permitting and licensing platform built specifically for local governments — has real results behind it: customers report cutting daily administrative work by as much as 87%, and Lakewood, Washington cut general permit processing times by 22% after switching to it. That's a genuine efficiency gain, not a number pulled from a press release. But notice what that number actually measures: one department's own software. Building & Safety, Planning, Fire, Health, and Engineering typically each control their own budget and their own procurement, on their own timeline, answering to their own funding. One department buying great software doesn't obligate the department down the hall to buy anything, let alone the same thing — and it says nothing about what a county-level agency reviewing the same project happens to be running.

  • The Real Variable. That's really the same fragmentation that shows up everywhere in permitting, just visible in a new place. It's not only that every jurisdiction sets its own process and its own requirements — it's that a lot of what actually happens to your application comes down to something a lot less official than any of that: who's reviewing it that day, what kind of mood they're in, whether they're rushing to get to something else before you've even finished explaining the scope. That same autonomy governs procurement, too. What a department can actually afford to buy, staff, or maintain depends entirely on that department's own resources, independent of whatever the department next door decided to do.

  • Why It Happened This Way. EPIC-LA turning out the way it did isn't a coincidence. Tyler rarely sells permitting on its own — it enters through a city or county's finance or HR relationship and expands sideways into permitting as an add-on module, which is exactly how EPIC-LA ended up running on EnerGov in the first place. That's a big part of why Tyler shows up in thousands more government contracts nationally than a permitting-first company like Clariti. The trade-off is documented beyond just our own experience, too — government buyers on G2 report integration errors between Tyler's EnerGov permitting module and its Munis finance system, including duplicate invoicing, and smaller jurisdictions say the platform carries more overhead than their actual permit volume needs. Broader adoption bought through an enterprise bundle isn't the same thing as a better experience. Sometimes it just means a whole jurisdiction standardized on something clunky together, instead of one department choosing something good.


RE: Didn’t Get the Memo

Here's what makes permitting's version of this problem stand out: everywhere else in design and construction, this got solved.

  • The Shift. Every other corner of the industry has been moving toward the same idea for a while now: keep a project in one connected data environment instead of scattering it across email, a scheduling tool, a separate document platform, and whatever the field team happens to be using for punch lists that week. Concept, design, construction, and operations increasingly live on one continuous thread instead of getting rebuilt from scratch at every handoff.

  • The Receipts. That shift isn't happening because connected data sounds nice on a slide. It's happening because disconnected data is expensive, and the industry has the numbers to prove it. Autodesk and FMI, a construction industry research and consulting firm, put a number on it a few years back: bad data — inaccurate, incomplete, hard to find, or just out of date — cost the global construction industry an estimated $1.85 trillion in 2020, with nearly $89 billion of that in rework alone. Almost a third of the people surveyed said more than half of their own project data was bad. That figure's a little dated now, but newer research backs the same pattern: Autodesk's 2025 industry survey found that the most digitally mature firms feel confident about their financial performance at a rate 30 points higher than the least mature ones — 82% versus 52%. Connect the data, and companies feel better about their numbers. That's not a coincidence.

  • Same Push, Different Vendors. Autodesk has put its own name where its argument is. Autodesk Construction Cloud — the umbrella that used to hold Build, Docs, BIM Collaborate, and Bridge as separate-sounding products — has been folded entirely into one brand, Forma, spanning design through operations. Procore is making the same case from the general contractor's side, positioning its own platform as one continuous record from preconstruction through field execution to the financials, so nothing gets re-entered or re-explained every time a project moves to its next phase.

Pick whichever platform you want — the direction everyone's headed is the same: fewer tools, fewer handoffs, one continuous record. Permitting is one of the only pieces of a project that still hasn't been pulled into that picture.

RE: Automated, Mostly by Humans

The permitting-tech category has a harder problem to be honest about: a lot of it isn't actually automating the process it claims to modernize — it's routing that process through people, then selling the wrapper as the product. PermitFlow is the clearest example, and it's surprisingly transparent about it once you look past the marketing: full national coverage across thousands of jurisdictions requires people, so alongside its research and filing tools, PermitFlow employs its own in-house expediting staff for quality review before submission, then files with the AHJ through whatever channel that jurisdiction actually accepts — a portal, an email, or, in plenty of cases, a human being physically standing at a counter.

None of that is a criticism of PermitFlow specifically — it's just an honest description of what permit expediting actually requires right now, in nearly any jurisdiction in the country. It's also, not coincidentally, what firms like ours have been doing for years, minus the software layer marketed on top of it. So the real distinction here isn't software versus people. It's that a lot of what gets sold as permitting technology is, underneath the interface, the same expediting work the industry has always relied on. Which means the actual opportunity to modernize isn't a new front end for that same service — it's connecting that service directly into the data environment the rest of the project is already living in, instead of leaving permitting off to the side, reporting back over email.

That's the gap this case study is actually about.


RE: Building the Case

RE: The Project

An affordable housing project, submitted through MIIP — Los Angeles City Planning's Mixed Income Incentive Program, part of the city's Citywide Housing Incentive Program framework — with a scope that required 25-plus individual approvals across departments and outside reviewing agencies. The project had already been in plan check for six months by the time we were brought on. It wasn't stuck because the scope was unusual. It was stuck because nobody was actually running it.

RE: The Problem

The architect of record wasn't working off a single source of truth, and it showed. Project files were piecemealed across whatever platform, inbox, or folder each party happened to be using, and multiple team members were routinely unsure which version of a given file was actually current. Different people were responsible for different reviews inside that same stack of 25-plus approvals, and in several cases entire sub-consultants had been brought on just to own one review apiece. Nobody was tracking all of it. There was no single project manager whose job was to know, at any given moment, where every one of those 25-plus reviews actually stood. The team wasn't small or inexperienced — it was just running without a shared record, which meant six months could pass without anyone being able to say with confidence what was done, what was outstanding, and what was even the latest version of the drawings in question.

RE: The Workflow

Here's what changed once the project moved onto Autodesk Forma's common data environment, broken down by the specific capability doing the work.

  • Data Management. The single biggest fix was also the simplest to state: one current record of every project file, in one place, instead of scattered across whoever last touched it. That alone resolved the "which version is real" problem that had been quietly stalling coordination for months. It also changed how comment responses got handled — instead of trying to reconstruct what had already been addressed from memory or a chain of emails, responses to plan check comments could be compared directly against version history, so it was immediately clear what had actually been resolved and what still needed work.

  • Issues and Reports. Every one of the 25-plus reviews got tracked as a live record instead of an item someone had to remember to follow up on. That gave the team a single, consolidated, real-time view of exactly where each review stood, available 24/7 — a genuine step up from the prior setup, where status on any given review depended entirely on whether someone thought to ask the right sub-consultant that week.

Snippet of a construction project schedule specifically focused on Building Permit tasks
  • Schedule and Workplans. The project schedule moved into the same ecosystem as everything else instead of living on a separate scheduling tool that only some of the team ever opened. With 25-plus approvals in motion, that mattered more than it would on a simpler project — schedule risk on any one of those reviews was now visible in the same place as the rest of the project's forecasting, not siloed off in a tool half the stakeholders never checked.

  • Bridge. The AOR, the sub-consultants, and the outside reviewing agencies on a project like this one don't run on the same systems or the same templates. Every firm has its own version of how it tracks a project, built up over years of doing it that way. Bridge is the capability built for exactly that mismatch — it's what lets teams keep working inside their own proprietary templates and workflows while still syncing back to the same shared environment, instead of forcing everyone onto one party's system or leaving them to reconcile everything by hand.

RE: Connecting the Dots

None of this replaces the actual expertise permitting still requires — knowing what a jurisdiction will actually flag, reading a scope correctly before it's submitted, knowing which comments are worth pushing back on. What it removes is the translation layer: the gap between what's happening across 25-plus individual reviews and what the rest of the project team actually knows about any of them at a given moment. That gap is where six months disappear without anyone noticing until it's a problem.

There's no fixed rulebook to master here and be done with it — permitting is closer to a conversation that resets with every reviewer, every jurisdiction, every project. You don't win that conversation by waiting for an agency to standardize it, because it won't, not in a way you can plan a project around. You win it by having your own repeatable process for having that conversation well: knowing how to reframe a comment instead of just answering it, knowing who else can look at the same scope with a different read, knowing when to resubmit and when to escalate. That part doesn't depend on which software the AHJ happens to be running.

If your team is already living inside a connected data environment for design and construction, permitting — even permitting this complex — shouldn't be the one workstream still running on scattered files and nobody's full-time job to track. Reach out and we'll walk through what connecting it actually looks like on your next project.


Company and platform names referenced above are used for identification and commentary only. Views on their effectiveness reflect our own analysis and firsthand experience working with these systems as permit expediters, not an evaluation on behalf of, or endorsed by, the companies named.

Next
Next

All Things RE: Development, Issue 002