Your Building Department Needs a Technology Strategy
Most building departments adopt technology reactively — one vendor at a time, one problem at a time. The result is a patchwork of systems that don't talk to each other and a staff that spends more time managing tools than using them.
By Will Maclean
Building departments are not technology organizations. They are regulatory agencies staffed by code professionals whose expertise is in construction, fire protection, and public safety — not software procurement. This is fine. It is also why most departments end up with a technology stack that looks like it was assembled by accident. Because it was.
The typical pattern: a department implements an e-permitting platform to replace paper intake. A few years later, they add a digital plan review tool to replace printed plan sets. Then a GIS integration for addressing and parcel data. Then a separate system for inspection scheduling. Each tool was purchased to solve a specific problem. None were purchased with an understanding of how they would work together.
The result is a collection of systems connected by manual workarounds. A permit technician enters the same applicant data into three platforms. A reviewer exports a comment from the plan review tool, reformats it, and pastes it into the e-permitting system. An inspector looks up the project in one system and logs the inspection in another. The technology was supposed to save time. In many departments, it has added steps.
The Integration Problem
The root cause is not bad purchasing decisions. It is the absence of a purchasing framework. Each tool was evaluated independently against the specific problem it was intended to solve. The e-permitting RFP asked about intake features, fee calculation, and public-facing portals. It did not ask about API endpoints for plan review integration. The plan review tool was evaluated on markup capabilities and collaboration features, not on whether it could pass structured data back to the permitting system.
This produces a specific set of failure modes:
Data lives in silos. Applicant information in the e-permitting system, review comments in the plan review tool, inspection results in the scheduling system. A building official who wants to understand the complete lifecycle of a permit — from application to certificate of occupancy — must check three systems and mentally assemble the picture.
Staff carries the integration burden. When systems do not exchange data automatically, people exchange it manually. This is invisible in the budget — it does not appear as a line item — but it consumes hours of staff time every day. A department with four disconnected systems and five permit technicians may be spending the equivalent of one full-time technician just on data re-entry and cross-system reconciliation.
Reporting is unreliable. When the source of truth is distributed across multiple platforms, aggregate reporting requires manual data assembly. Review time metrics come from one system, application volume from another, inspection pass rates from a third. The numbers may not reconcile because the systems define projects, dates, and statuses differently.
What a Technology Strategy Looks Like
A technology strategy for a building department does not need to be a 50-page document. It needs to answer four questions:
What is the system of record? One platform should be the authoritative source for permit data — application status, review outcomes, inspection results, and issuance. Every other tool feeds into or reads from this system. The system of record is almost always the e-permitting platform, because it spans the entire permit lifecycle.
What are the integration requirements? Before purchasing any new tool, the department should define how data will flow between the new tool and the system of record. This means asking vendors specific questions: Do you have an API? Can you push review comments directly to our e-permitting platform? Can you pull application data automatically, or does someone re-enter it? If the answer is manual re-entry, that cost needs to be factored into the total cost of ownership.
What is the data model? A permit is not the same thing across all platforms. In the e-permitting system, it might be defined by a permit number. In the plan review tool, by a project ID. In the inspection system, by an address. If these identifiers are not mapped to each other, cross-system queries become manual investigations. Defining a consistent data model — even informally — prevents this fragmentation.
What is the upgrade path? Technology in this space is moving fast. AI-assisted review, automated compliance checking, and computer vision for drawing interpretation are shifting from experimental to operational. A department that locks itself into a vendor ecosystem with no API access and proprietary data formats will have difficulty adopting these tools when they mature. The strategy should favor platforms that export data in standard formats and provide API access for future integrations.
The AI Layer
AI-assisted plan review adds a new category to the building department technology stack, and it illustrates why the integration question matters. An AI compliance checker needs to receive plan submissions — either directly from the applicant or from the e-permitting platform. It needs to return results — flagged conditions, compliance assessments, suggested corrections — to the reviewer, ideally within the review tool they already use.
If the department's technology stack has no integration layer, the AI tool becomes another silo. The reviewer checks the AI results in one window, the plans in another, and enters comments in a third. The efficiency gain from automated checking is partially consumed by the manual process of moving results between systems.
If the stack has an integration layer — even a simple one, like API-based data exchange between the e-permitting platform and the AI checker — the results flow automatically. The reviewer sees flagged conditions alongside the plans. The correction comments populate in the permitting system. The AI tool becomes part of the workflow rather than adjacent to it.
Procurement Implications
Building departments typically purchase technology through municipal procurement processes that evaluate tools independently. An RFP for a plan review platform will be evaluated by a selection committee that scores features, price, and vendor viability. Integration with existing systems may appear as a scored criterion, but it rarely receives the weight it deserves.
The corrective is to evaluate tools as additions to a stack rather than standalone purchases. This means:
- Including IT staff or a technical advisor in the evaluation of building department tools
- Requiring API documentation as a mandatory submission element in RFPs
- Scoring integration capability as a primary criterion, not a secondary one
- Requesting references from jurisdictions that use the same e-permitting platform
This is not about buying the most expensive or most technically sophisticated tool. It is about ensuring that each purchase makes the overall system more capable rather than more fragmented.
Start Where You Are
Most departments reading this already have a patchwork stack. The strategy does not require replacing everything. It requires defining the system of record, documenting the current integration points (and gaps), and making the next purchase with the full stack in mind.
The departments that do this well do not spend more on technology. They spend the same amount more effectively, because each tool augments the others rather than operating in isolation. The ones that do not end up with a technology budget that grows while the staff experience worsens — more systems, more re-entry, more workarounds, less time for the actual work of reviewing plans and inspecting buildings.
A building department does not need to become a technology organization. It needs to make technology decisions like one.