Building Software Municipalities Love

The first time I sat with a building department and watched staff process permits, I realized how much context you need to build software for this space. A single permit application touches fee calculations, zoning rules, document requirements, inspection sequences, and notification workflows, and every municipality handles each of those differently.

After 20+ years of building enterprise software for local government, the lesson I keep relearning is that the details matter enormously. The gap between software staff tolerate and software they actually want to use comes down to how deeply you understand the work they do every day.

Every Municipality Is Different

A building permit in one municipality might require three reviews and two inspections. The same permit type in the next town over might require five reviews, a separate fire department sign-off, and a completely different fee structure. Zoning overlays, local bylaws, regional building codes. They all layer on top of each other in ways that are unique to each jurisdiction.

This is why most legacy permitting systems feel like they’re fighting the people using them. They were built around a generic process model and expect municipalities to adapt. When the software can’t accommodate a local variation, staff build workarounds (spreadsheets, sticky notes, manual email chains) and the system becomes one piece of a fragmented workflow instead of the single source of truth it was supposed to be.

Civaptic takes the opposite approach. Permit types, review workflows, fee schedules, inspection sequences, and notification templates are all configuration, not code. Each municipality defines how their processes actually work, and the platform adapts to match.

Ship Early, Learn Fast

There’s a principle I’ve come back to throughout my career: no matter how thorough your research, no matter how many stakeholders you interview, the first version of any feature will be approximately right and precisely wrong in ways you didn’t expect.

The only way to close that gap is to get working software in front of real users as quickly as possible. Not mockups. Not slide decks. Actual working features in actual workflows. A demo shows you what people think they want. Usage shows you what they need, and the faster you learn the difference, the less time you spend building the wrong thing.

This is why we treat our early municipal partners as collaborators, not just customers. Their feedback doesn’t go into a backlog to be prioritized later. It shapes the next iteration directly.

Three Principles We Build To

Every feature in Civaptic is evaluated against three principles:

Intuitive. Staff should always understand what they’re looking at and what action to take next. A permit reviewer shouldn’t need to memorize status codes. An inspector shouldn’t need a manual to record results. The system should guide people toward the right action and make mistakes difficult.

Efficient. The system should reduce the effort required to get results, not add to it. If generating a report takes long enough that staff schedule it for after hours, the software has failed at its job. Performance should be invisible, fast enough that it never becomes a factor in how people work.

Effective. The data is correct. The fee calculations are correct. Validation catches errors before they propagate. When staff rely on the system for compliance checks, fee totals, or status reporting, they need to trust what they see without second-guessing it.

These aren’t aspirational statements on a slide. They’re the filter we apply to every product decision.

Building With Municipalities, Not Just For Them

The municipalities who use Civaptic are partners in building it. Their edge cases make the product stronger. Their domain expertise surfaces things that no amount of internal testing would catch. Their daily workflows reveal where the design is working and where it falls short.

Because at the end of the day, the goal isn’t to build software that’s “better than the last system.” The bar is higher than that. We’re building software that makes public service easier, faster, and more reliable. Software that municipal staff actually want to use.

That’s what we’re working toward, every day.