A city published its requirements. Here is a working prototype, built against them.
The City of Medina published a permitting-software RFP in February 2026. Its own words describe the target: about 2,700 records and 2,400 inspections a year, seven staff users with three in the field, and ten enumerated capabilities it wants software to provide. Its published permit applications are PDF forms, most with a fee line left blank for staff to complete, and it asked vendors to move submission, payment, and inspection requests online. Proposals closed March 13.
This is that list, working, graded item by item below. Residents pick a permit type, see the fee calculate as they type, submit, and watch their permit move through its stages, up to five depending on type. Staff run the demonstrated process from one screen, and the software refuses the illegal moves a paper process cannot: no inspection scheduled before fees are paid, no duplicate of an open inspection, no permit issued while a required inspection is open. Inspectors close permits from a phone, and a failed inspection books its own redo. It was built and red-teamed across two working sessions on August 2, 2026, then hardened through a further cross-model QA cycle the next day, from the city's published documents, as an independent exercise without stakeholder access; the catalog and form fields are the city's own, the fee amounts and workflow sequence are labeled assumptions, and discovery with the agency is where a real deployment would begin.
Demonstration only, with synthetic seed data; all names are fictional and anything you enter stays in your browser. Not a bid; not affiliated with, endorsed by, or submitted to the City of Medina, Medina County, or any software vendor. The city's contractor registration now runs on a commercial permitting platform and its permit applications remain PDF forms as of August 3, 2026; this exercise analyzes a closed public procurement. Contact: michael@vismu.co.
00 / What to try first
Follow one permit through it.
- Apply: pick "Building Permit & Zoning Certificate," look up parcel 028-19A-24-071, enter an estimated cost and a one-line scope, leave the default improvement and use choices alone, add a name and an email, and watch the fee build itself as you type the cost. Submit and keep your record number.
- Records: find your record and advance it to Review, then to Fees Due. There the advance control disappears and a gate takes its place: record payment to advance. Skipping ahead is not on the menu.
- Pay: record the simulated payment. The record moves itself to Inspection. Schedule a Footing inspection, then try to schedule a second Footing: the software refuses, and says why.
- Field: open the Field tab, sized for a phone, and press Fail on the Footing. A reinspection books itself for three days out, and a banner confirms it.
- Finish it: pass the reinspection, then Framing and Final the same way: schedule each from the record's detail page, pass each in Field. When the last required inspection passes with nothing open and fees settled, the permit issues itself and the banner says so. No one had to remember.
Then break it on purpose. Look for a way to advance an unpaid record, schedule a duplicate of an open inspection, or renew the expired contractor whose insurance has lapsed. Some illegal moves get a written refusal that names the reason; the rest are simply not offered. Both are the demonstration.
01 / The ten requirements
Every RFP requirement, mapped and graded honestly.
The RFP enumerates ten required capabilities. The grades below are deliberately strict: BUILT means the demo does the thing end to end; PARTIAL means a meaningful subset works and the gaps are named; SIMULATED means a real integration is stood in for; PLATFORM means it belongs to production infrastructure, not this build; PLANNED means it is scoped but not built. A demo that grades itself generously would be arguing against its own thesis.
| # | City's requirement (paraphrased from the RFP) | What the demo does, and does not | Grade |
|---|---|---|---|
| 1 | Records for permits, code enforcement, contractor registration, and boards/commissions; workflow steps for submittals, reviews, fees, and inspections; links to related records, parcels, fees, inspections, contacts, and documents; multi-department access; staff customization of records, inspections, and fees | Does: one record store, guarded workflow, parent-child links (trade permits link their building permit at intake), fees, inspections, documents-by-name, notes. Does not: code-enforcement or board record types, contact records, roles or per-department access, staff-customizable fields | PARTIAL |
| 2 | Online applicant interface: submit applications and documents, pay fees, request inspections, interact with staff, view records and access documents | Does: type-specific submission, live fee preview, status tracker. Does not: real payment, real document upload or access, applicant-initiated inspection requests, two-way messaging | PARTIAL |
| 3 | Automated temporal renewals, such as annual contractor registration | Does: watches expirations, queues eligible registrations, generates a linked renewal once per source record. Does not: run on a schedule without a staff click; window and term are assumed | PARTIAL |
| 4 | Create, assign, customize, and track inspections | Does: scheduling, assignment, tracking, results, automatic reinspection after a failure, latest-attempt-per-type governs issuance. Does not: staff-customizable inspection types (the taxonomy is assumed) | PARTIAL |
| 5 | Field use on mobile devices | A phone-width worklist where an inspector records pass/fail and notes on site; failing schedules the reinspection automatically. Does not: offline capture; the worklist is the one demonstrated field surface | BUILT |
| 6 | Automatic fee generation from record information | Does: fees compute from type and valuation at draft time and gate the workflow. Does not: use the city's adopted amounts. Every amount and formula here is an assumption, labeled in the interface; the city's Building Department fee link still returned 404 when checked (2026-08-03), and its adopted Planning & Zoning schedule (Ordinance 98-26, effective 7/8/2026) is published but not incorporated | PARTIAL |
| 7 | Off-site or cloud data storage sized to the department | Demo persists locally in the browser by design (no real data should exist here). Production storage is a platform concern | PLATFORM |
| 8 | Integration of Medina County Auditor property data, preferably auto-updating | A parcel lookup by PPN pre-fills property data from a fabricated feed, refreshed only on lookup. The county engineer publishes daily parcel shapefiles and the Auditor's appraisal data; wiring the real feed is a build item, so this stays simulated | SIMULATED |
| 9 | Customizable reporting for records, inspections, and fees, exportable to PDF, CSV, or Excel | Does: fixed operational summaries, records CSV, inspections CSV, with fee totals carried on records. Does not: user-configurable reports, filters, or chosen dimensions | PARTIAL |
| 10 | Migration of all data and documents from the current software | Not buildable without the incumbent's export; treated as its own phase with a parallel-run gate in the plan below | PLANNED |
02 / Honesty ledger
Which rules are the city's, and which are mine.
| Status | Items |
|---|---|
| SOURCED | The 19-type application and permit catalog (the city's page lists 4 applications, 12 permits, 4 planning/zoning entries; the Board of Building Code Appeals application is out of demo scope); the Building Permit form's fields (PPN, lot, historic-district flag, improvement and use types, construction classes I-A through V-B, sub-permit cross-references); the four workflow components the RFP names (submittals, reviews, fees, inspections), but not their sequence; volumes, user counts, dates, and population from the RFP; the adopted Planning & Zoning Fee Schedule (Ordinance 98-26, effective 7/8/2026); the Building Department fee link that still returned 404 when checked (2026-08-03) |
| DEMONSTRATED | Everything the demo actually executes: guarded transitions, fee gating, reinspection-after-failure, latest-attempt supersession, renewal generation with a once-only latch, exports |
| ASSUMED | All fee amounts and formulas; the workflow SEQUENCE and which stages a permit type passes through; which types require plan review (the demo routes review and non-review types differently, all assumed); the required-inspection set per type; the inspection taxonomy; the 60-day renewal window and 365-day registration term; the three-day reinspection interval; contractor registration handled in-catalog (the city runs it through a separate portal); the simulated payment step; document handling as names only; the parcel feed's behavior; the named inspectors; browser-local persistence; the fixed export layouts |
| UNKNOWN | Everything only discovery can supply: the real fee schedule, exception paths, the Auditor feed's shape, the incumbent's export, counter traffic, multi-department permissions, the Director's success measures |
The role this exercise responds to pairs a forward-deployed PM with a forward-deployed engineer: reusable scaffolding versus per-agency configuration. The demo tags its views accordingly, labels the assumed fees, renewal window, and inspection taxonomy in place, and this ledger is the same discipline applied to the claims.
03 / Discovery questions
What the RFP does not answer, and I would not guess.
A working prototype is not a deployment. These are the questions I would open discovery with. The public record answers more than a first pass suggests, and where it does, the question narrows to what only the agency can supply.
04 / Implementation plan
The rollout the RFP asked proposers to describe.
| Phase | Weeks | Work | Gate to proceed |
|---|---|---|---|
| Discovery | 1-2 | The questions above, on site; both adopted fee schedules and the building fee table captured as configuration; sample export obtained from the incumbent; role matrix drafted; baseline metrics recorded | Director signs the workflow map and fee tables; a written assessment of the sample export (fields, counts, quality) is accepted; the baseline is on file |
| Production build-out | 2-6 | The capabilities this demo simulates or lacks: payments, document storage, applicant messaging and inspection requests, roles and permissions, the Auditor data feed, configurable reporting, production hosting | Each capability demonstrated on real city cases in the sandbox, not on samples |
| Configuration | 3-6 | Permit catalog, forms, fees, and roles configured from discovery; staff walkthrough against real cases they choose | Staff complete five real record types end to end in the sandbox |
| Migration and parallel run | 6-10, conditional | Scope set by the discovery export assessment; full migration; new applications enter both systems; discrepancies logged | One full week of parallel operation in which every discrepancy is resolved, not merely explained, and record counts reconcile |
| Cutover readiness | 10-12 | Counter-assisted mode rehearsed with named staff; field devices in staff hands; support path with a named owner and response times; rollback plan written and tested against a copy | Staff, not the vendor, call the go date; the incumbent stays read-only, not off |
| Measurement | Weeks 12-25 | A 90-day scorecard from cutover against the baseline set in discovery, reviewed with the Director | Renewal decision made on the scorecard, not inertia |
Timeline honesty: every week above is conditional on discovery. The plan assumes the incumbent can produce an assessable export, the county's daily files are usable for permitting, staff are available for walkthroughs and parallel entry, and the adopted fee tables hold still. The migration window is set by the export assessment, not the calendar, and measurement starts at cutover, wherever cutover actually lands.
05 / Cost anchors
What the buyer budgeted, and what other governments have contracted.
The RFP requests costs as initial setup, recurring, and miscellaneous. Inventing a vendor quote here would be theater; what the public record supports is a buyer-side budget anchor and a set of public contract anchors, each checked against its primary council document before inclusion. These are contracts of differing scope, module count, and volume, not normalized market prices, and they are adopted price schedules and contract authorizations, not audited payment histories: read them as range and structure, not as a quote.
The buyer's own anchor: Medina's authorizing Ordinance 215-24 estimated "$50,000.00 for initial setup and $35,000.00 annually" for these services. Against the RFP's ~2,700 annual records, the city's own recurring budget is about $12.96 per record per year, with all the limits of a budget estimate.
| Government (2020 pop.) | Setup | Recurring | Term | Public record |
|---|---|---|---|---|
| Medina County, OH (the city's home county, 2026) | $59,500 | $72,500/yr | 5 yr; $132,000 Year 1 | Resolution 26-0476 |
| Peekskill, NY (25.4k), ~48 planning matters/yr | $5,000 | $15,000/yr | 2-yr minimum | Adopted minutes, Feb 2026 |
| Manor, TX (13.7k) | $0 (discounted) | $34,000/yr | 3 yr | Council order form, Nov 2025 |
| Panama City, FL (32.9k) | $14,500 | $33,000/yr | 3 yr; $113,500 Cloudpermit; the approved stack adds DigEplan plan review at $39,500, $153,000 all in | Agenda item, Mar 2024 |
| Gadsden, AL (33.9k) | not separately stated | $59,000 y1; $39,000 y2-3 | 3 priced yrs | Resolution R-466-24 |
The parametric model a real quote would need: users and field seats, annual record and inspection volume, migration scope from the incumbent's sample export, document storage, integration count and depth (Auditor feed, payments), training and counter-assisted intake, support tier, and an uncertainty band that narrows at each discovery gate. Each is a line an owner can check, not a contingency bucket.
06 / Colophon
How this was made, and what it does not claim.
- Sources: the city's published RFP, its applications and permits page, its published Building Permit and Electrical Permit PDFs, its adopted Planning & Zoning Fee Schedule (Ordinance 98-26), and Ordinance 215-24. Cost comparables arrived as external research leads and each included figure was re-verified against the primary council document before use.
- Build: agentic tools end to end (Claude Code driving research, extraction, code, and browser verification), across two working sessions on August 2, 2026, with a cross-model adversarial review (OpenAI Codex) between them. The review found real defects across successive rounds: an issuance path that skipped payment, a stricter round that found the workflow could still be bypassed by early payment and by single-inspection issuance, discarded form fields, unescaped stored input, UTC date handling, and overstated capability grades. A further QA cycle ran August 3: a second Codex source review plus an independent live browser test run, merged and adjudicated, which surfaced and fixed additional workflow-integrity defects (duplicate-inspection issuance, a double-click acting on the wrong record, silent save-failure feedback), each re-verified against the live deployment before this page was updated. The review-then-fix cycle across independent models is the process this exercise is meant to show.
- Truth standard: factual claims about the city cite its documents; everything simulated or assumed is labeled in place and in the ledger above. Where a claim could not be verified, it was removed or downgraded rather than hedged.
- What this does not claim: stakeholder discovery, which no artifact can perform; client delivery or commercial outcomes, which belong to real engagements; a production security or reliability posture beyond output escaping and stored-state validation; QA beyond the review cycles described; or any affiliation with the City of Medina, Medina County, GovWell, or Concourse.