Municipal Software Problems: The 7 That Stall Permits and 311, and How to Avoid Them

Why does one permit type turn into six departments so often?

A city scopes a first release around building permits. Discovery starts, and within three weeks Fire wants their conditional review in the workflow, Engineering wants creek setback logic, Planning wants entitlement conditions to carry into the permit, Public Works wants encroachment permits in the same system, and the sanitary district asks whether they could get a login too. Nobody in the room is wrong. A commercial tenant improvement really does touch all of them.

What makes this specific to cities is that departments are separate budgets with separate directors, and a software project is the first neutral table they have shared in years. So the project becomes the venue for a reorganisation nobody scheduled. The result is a scope priced like the $150,000 to $400,000 full platform, delivered on the schedule of the slowest department, with the sponsor changing after an election.

The fix is to make the first release one permit type end to end plus 311 intake and status, on top of the address and parcel service, at $60,000 to $130,000 over 12 to 16 weeks. That is deliberately chosen so a cycle time number reaches council inside one budget cycle. Additional departments join as configuration of routing rules rather than as new development, which is only possible if routing was built as data your Building Official edits rather than as code. Say that out loud in the kickoff and hold it.

What goes wrong when you migrate twenty years of permit records?

Extraction is the easy part. The problem is that a meaningful share of your historical records carry addresses that never matched a parcel in the first place, because they were typed at a counter by a contractor in 2007 and nobody validated anything. Some are misspelled, some reference streets that were renamed, some belong to parcels that have since been split or merged, and some are for structures that no longer exist.

Cities discover this at the worst moment, when the migration script runs and reports a large block of records with no parcel match. At that point there is a choice nobody prepared for: guess, or stop. Guessing is how code enforcement history ends up attached to the wrong property, which is a genuine legal exposure the first time a case is challenged.

The second issue is your vendor's extraction terms. Confirm in writing what format you can get, at what cost and on what notice, before you sign anything with a new developer. Some cities find their exit is a fee and a wait they did not budget.

The pattern that works is to treat migration as its own workstream with named staff, not a task inside development. Migrate open and recent records fully, migrate closed history into a read only archive linked to the parcel where a match exists and flagged where it does not, and let your staff adjudicate the exceptions rather than a script. Budget 3 to 5 weeks of a records person's time and say so in the project plan.

Why do the Munis, ArcGIS and Cityworks integrations break after launch?

Each one fails in a different way and all three are predictable. Munis or Naviline is usually the hardest, because on older instances there is no usable interface at all, so the real design is a scheduled file exchange plus a reconciliation report. That works, and it breaks when finance changes an object code and nobody tells the development team, so postings land in suspense and are discovered at month end. The fix is a daily reconciliation that alerts on unmatched postings rather than a nightly job that assumes success.

ArcGIS breaks when the parcel layer is republished. Your GIS analyst updates a feature service, field names shift slightly or a domain value changes, and the address service starts failing matches silently. Consuming a live feature service is the right architecture, and it needs a schema check on every refresh with an alert when the shape changes.

Cityworks breaks around identity. A 311 request creates a work order, but if the work order ID is not written back to the request, the two records drift apart the first time a crew closes the job in the field. Then the resident never hears anything and reports the same pothole again.

The common fix is to require the developer to name the specific system, the specific method and the specific failure alert for each integration in the statement of work. There is a large gap between saying they do interfaces and having reconciled a fee posting into a live general ledger.

What happens when accessibility and records law are treated as a QA pass?

Anything resident facing carries WCAG 2.1 AA and Section 508 obligations, and a VPAT will be asked for. Cities that treat this as a testing activity at the end pay twice, because the failures are structural: custom form controls that no screen reader announces, error messages conveyed only by colour, a map interface with no keyboard path, a payment step that traps focus. Fixing those means rebuilding the interface, not adding attributes.

Records law fails more quietly. Your retention schedule is a PDF staff mostly remember, so nobody attaches retention rules to record types at creation. Two years later disposition is a manual project and a records request forces a search across the permitting system, Laserfiche, six inboxes and a shared drive against a short statutory clock. GovQA or NextRequest tracks the request. Neither finds the documents.

The fix is to make both design constraints. Accessibility means keyboard paths and real screen reader testing from the first screen, with a VPAT as a deliverable. Records means retention attached at record creation, an audit log designed for a court rather than for debugging, and an indexed search across the systems you already own with staff approving every redaction before release. Nothing auto releases, ever.

Should you build custom or configure what you already own?

There is a real class of city that should configure and stop. Under roughly 25,000 residents, under about 1,500 permits a year, no full time IT staff, no unusual overlay districts or local amendments: take OpenGov ViewPoint or CityView, adopt their process exactly as written, resist customising, and you will be fine. The mistake at that size is buying an enterprise platform and then paying to make it act like your city.

Even when you do build, keep your systems of record off the shelf. Do not rebuild Munis, ArcGIS, Laserfiche or Granicus. They are good at what they do and rebuilding any of them is how a city project ends up in the newspaper. Keep Accela or Tyler EnerGov too if your process genuinely fits the product and your change orders are rare.

The signals that justify building are concrete. You have spent more on change orders and professional services than on licence in the last two years. A workflow that matters runs on a spreadsheet one planner maintains. Three or more systems require a human to re key between them. Your permit cycle time is a council agenda item. You have missed a statutory records deadline. Or your vendor quoted you to extract your own data. Any two of those and the build is cheaper than the status quo.

How do hidden costs get into the quote?

The first is migration, which almost every quote understates because it is priced as a data load rather than as adjudication of two decades of unmatched addresses. Ask for it as a separate line with named city staff attached.

The second is the number of departments in a single workflow. Each additional reviewer is a stakeholder with their own conditions, their own turnaround expectations and their own opinion about serial versus parallel review, and each one adds discovery time rather than development time. Six departments is not twice the cost of three, it is roughly twice the calendar.

The third is payments. Contain PCI scope by tokenising through a processor you already use such as Point and Pay or Invoice Cloud, so card data never touches your application. Quotes that assume a card form in your own interface are quoting a compliance programme without saying so.

The fourth is hosting posture. If your state, your insurer or your cyber policy expects StateRAMP or SOC 2, that is architecture and evidence work, not a hosting line item. The fifth is multilingual resident facing screens, including transactional email and receipts rather than only the form. The sixth is procurement itself, where the request for proposals cycle, security review and insurance requirements add weeks that have nothing to do with code.

What separates a municipal build that works from one that fails?

The first separator is the data model. Ask the developer to model parcel, address, record, review, condition, fee, inspection and case on a whiteboard before any contract. If they cannot explain how a lot line adjustment splits history, or why a fee needs an effective date and a stored formula version, they will learn on your budget.

The second is whether fees are versioned configuration. Council adopts a fee resolution, someone stages the new version, and it goes live at midnight on the adoption date, with every past calculation storing its inputs and its formula version so a fee assessed in 2024 still recomputes exactly as it did in 2024. That single property ends fee disputes and audit findings, and it is the thing a vendor scripted fee engine cannot give you.

The third is whether routing is data. If adding Fire as a conditional reviewer requires a developer, you have rebuilt the vendor relationship you were escaping. Your Building Official should edit that rule directly.

The fourth is realistic use of AI: completeness screening, 311 deduplication and routing, and proposed redactions, with a staff member approving before anything is issued or released.

The last is ownership and exit, in writing before kickoff: your code in your repository, your data in your cloud account, documented schemas, and a stated cost to hand the whole thing to a different firm. A developer who resists that clause is telling you what the next five years look like.