How to evaluate permitting and licensing software

What the software does

Permitting and licensing software takes an application from a resident, contractor or business, checks it, routes it to the reviewers who must approve it, collects fees, schedules inspections and issues the permit or license. The rules it enforces are your own: local codes, ordinances and fee schedules. So the real question in an evaluation is less what the product can do than how faithfully, and by whom, your rules can be set up and kept current in it. This guide sets out what to ask and test, and names no vendors.

Most products cover:

• Online applications that help applicants find the right permit or license type, upload documents and see the fees.
• Intake, where staff check completeness and send back what is missing.
• Plan review routed to building, zoning, fire, engineering and health reviewers, often in parallel, with comments and resubmittals.
• Fees and payments calculated from your schedule and taken through a payment processor.
• Inspections requested, scheduled and resulted in the field.
• Issuance and renewal, with status visible to the applicant throughout.
• Reporting on workload and service for managers and elected officials.

Who should be on the evaluation team

• Permit technicians and licensing clerks who work the counter and the intake queue.
• Plan reviewers from each discipline, and inspectors who will use it in the field.
• Department directors who own service targets and report to elected officials.
• Finance and the treasurer's office, for fees, refunds, cashiering and the general ledger.
• GIS staff, who maintain parcel, address and zoning data.
• IT, for integrations, identity and data migration.
• Records management and the city or county attorney, for retention and public records requests.
• The ADA coordinator or accessibility lead.
• Frequent applicants, such as a contractor and a small business owner, to test from the outside.

Questions to ask and things to test

• Which types go first. Name the permit and license types you would put online first and the departments that review them. Ask the vendor to configure one of each with your real questions, documents and routing.
• Fees. Load part of your fee schedule, including a valuation-based or tiered fee. How often does your schedule change, and can your staff make that change without the vendor?
• Integrations. Name your GIS services, payment processor and finance system. Ask the vendor to show each connection working, and what happens when one is unavailable.
• Keep or replace. Decide whether an existing land-management system stays. If it does, ask how records move between the two and which is the record of truth.
• Ownership after go-live. Ask who will maintain permit types, questions and fees, and have that person make a change during the evaluation.
• Plan review. Route a resubmittal through two disciplines and compare it with the previous round. If you mark up large-format drawings, ask whether that needs a separate plan review tool.
• Counter applications. Have staff enter an application for someone who cannot or prefers not to apply online.
• Accessibility. Ask for an accessibility conformance report for the applicant portal and test it with a screen reader and keyboard only.
• Success. Agree what a successful launch means for applicants, staff and elected officials before choosing, so every vendor is judged against the same measures.

Limits to probe

Ask vendors to state their boundaries in writing:

• Rules are yours. A guided application is only as accurate as the rules configured from your codes and fee schedules, and your staff maintain them after go-live.
• Decisions stay with people. Software does not interpret codes or approve permits; reviewers and inspectors decide.
• Money. Ask whether the vendor or your payment processor handles funds, and who is responsible for card data security.
• GIS. Parcel and zoning data are usually read from your GIS and must be kept current there.
• Drawing markup. Detailed review of large plan sets may need a dedicated electronic plan review tool.
• Code enforcement. Complaints, violations and enforcement cases may be outside the product.
• Applicant accounts. Online applications may require an email address; make sure counter service remains.
• History. Migration depends on the condition of your existing data. Older records may be referenced rather than fully migrated.

Regulations and standards to understand

Permitting and licensing law is mostly state and local, so your own codes, ordinances and counsel are the main authority. A few general rules apply widely:

• Web and mobile accessibility. The Department of Justice's ADA Title II rule (28 CFR Part 35, Subpart H) requires state and local governments' web content and mobile apps, including those provided through contractual or licensing arrangements, to meet WCAG 2.1 Level AA. An interim final rule published in April 2026 set the compliance dates at April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special district governments. The rule has limited exceptions; read them with counsel rather than assume portal content is exempt, and check ada.gov for current dates.
• Floodplain permits. Communities in the National Flood Insurance Program must, under 44 CFR 60.3, require permits for proposed construction and other development, review permit applications for flood safety, and in mapped flood hazard areas obtain and keep records of the elevation of new and substantially improved buildings. Test how the system captures and retains this.
• Card payments. If fees are taken by card, the PCI Data Security Standard applies to how card data is handled. Ask whether card details ever pass through the permitting system.
• Building codes. Most states and localities adopt building codes based on model codes, with local amendments. Ask how a code adoption cycle or a local amendment is reflected in application questions and review checklists.
• Public records and retention. Applications, plans, inspection results and decisions are public records under most state laws, subject to exemptions, and are covered by your retention schedules. Check how the system handles retention, exports and redaction.

Implementation risks

• Configuration effort. Turning codes and fee schedules into questions and rules takes longer than vendors expect. Start with high-volume, simpler types.
• Fee errors. A wrong fee is visible to every applicant. Test fee calculations against past applications before go-live.
• GIS data. Clean up parcels, addresses and zoning layers first, and agree how changes reach the permitting system.
• Migration. Decide what history is migrated, what is archived and how open permits in flight are finished.
• Applicant change. Contractors who apply often have habits built around the old process. Tell them early and keep counter help available.
• Inspector adoption. Test field use where connectivity is poor, and make sure results reach the record the same day.

Related reading on this site

Requirement pages: ADA Title II, WCAG 2.1, PCI DSS, State public records laws.

In the glossary: ADA Title II web rule, WCAG, PCI DSS.

This guide describes the category, not any one product. It is general information, not legal advice: for what a rule requires of your organization, read the rule itself or ask your counsel.