How to write a permitting software RFP

A permitting solicitation is usually written by copying the last one, which was written by copying a vendor's feature list. The result is a two-hundred-row requirements matrix where every bidder answers "yes" and the evaluation turns on price and references. Both of those matter, but neither predicts the outcome you actually care about: whether the system is in production and used within a year.

Three changes to how the document is written will tell you more than another hundred requirement rows.

Start from outcomes, not screens

A requirement that says "the system shall provide a dashboard" can be satisfied by anything. A requirement that says "a reviewer shall be able to see every permit assigned to them that is within five days of a statutory deadline, without running a report" can only be satisfied by a system that models statutory deadlines at all.[1]

Write requirements a vendor can fail. If every bidder can answer yes, the row is decoration.

The practical test: for each requirement, ask whether you can imagine a credible product that would have to answer "no." If not, delete it or sharpen it until you can.

Make implementation cost binding

Implementation is where permitting projects fail financially. The industry pattern is an estimate at proposal time, a discovery phase after award, and change orders that carry the real number. If the solicitation does not require a fixed price with a defined scope boundary, you will get an estimate.

Language worth borrowing: require bidders to state implementation as a fixed price for a scope defined in their own proposal, and to list every condition under which that price changes. The list is more informative than the number.

Ask about plan review precisely

"Does your system support electronic plan review?" is answered yes by every vendor, including those who resell a third-party markup tool connected by an integration. That integration is where comments get lost and versions drift.

Better questions: Is markup stored in the permit record or in a separate system? When an applicant resubmits, what carries forward automatically? Can a reviewer compare two revisions of the same sheet without downloading either? Who holds the support contract for the markup component?

Score accessibility as a line item

Under the ADA Title II web rule, public entities face dated conformance obligations for the digital services they offer.[3] A permitting portal is one of the most-used digital services a city operates. Ask for a current VPAT, ask when it was produced, and ask what is listed as not supported — the honest answer is never "nothing."

Reference questions that actually work

Vendors supply references who are happy. You are not trying to find an unhappy customer; you are trying to find out what the project felt like. Ask when the contract was signed and when the first permit was issued in production. Ask which modules are still not live. Ask how many change orders were executed, and for what. Ask who at the city did the configuration.

Notes & sources

Requirement phrasing adapted from evaluation criteria used in recent municipal permitting solicitations.Citation placeholder — replace with the specific solicitation reference before publishing.↩
Implementation-to-license ratios reported across public-sector permitting procurements.Citation placeholder — attach the source table used for the benchmark report.↩
U.S. Department of Justice, ADA Title II web and mobile accessibility rule, with compliance dates set by population.Citation placeholder — link the Federal Register entry.↩

Every claim on this page should resolve to a source a procurement officer can check. Placeholders above are deliberate — they mark where the real citation goes, and should not ship as-is.