A city published its requirements. Here is the working system, built against them.
In February 2026 the City of Medina, Ohio (pop. ~26,000) published an RFP for permitting and code-enforcement software: ten enumerated capabilities, real volumes (about 2,700 records and 2,400 inspections a year), seven staff users with three in the field, and a requested proposal structure. Proposals closed March 13. This is a retrospective forward-deployment exercise against that public document: a working demonstration system whose configuration comes from the city's own published forms and permit catalog, plus the implementation plan, discovery questions, and cost structure the RFP asked proposers to supply.
Demonstration only, with synthetic data. Not a bid. Not affiliated with, endorsed by, or submitted to the City of Medina, Medina County, or any software vendor. The city has since begun implementing its selected vendor; this exercise analyzes a closed public procurement. Contact: michael@vismu.co.
01 / The ten requirements
Every RFP requirement, mapped to the build.
The RFP enumerates ten required capabilities. The demo builds the workflow spine deep, simulates what requires external systems, and stubs what belongs to a production platform, with each status labeled honestly.
| # | City's requirement (paraphrased from the RFP) | In the demo | Status |
|---|---|---|---|
| 1 | Records for permits, code enforcement, contractor registration, and boards: general info, workflow steps, links to related records, parcels, fees, inspections, documents; multi-department access; staff customization | One record store drives every view. Workflow chevrons per record; sub-permits link parent-to-child the way the city's paper building form cross-references its HVAC, electrical, and plumbing permits | BUILT |
| 2 | Online applicant interface: submit applications and documents, pay fees, request inspections, interact with staff, view records | The Apply tab: dynamic forms per permit type, live fee preview, submission, and a public status tracker; payment and document upload simulated | BUILT |
| 3 | Automated temporal renewals, such as annual contractor registration | The Renewals tab watches expirations and generates renewal records with fees, exactly for the contractor-registration case the RFP names | BUILT |
| 4 | Create, assign, customize, and track inspections | Scheduling from any record; office-wide schedule view; results roll back into the record and can auto-issue the permit | BUILT |
| 5 | Field use on mobile devices | The Field tab: a phone-width worklist where an inspector records pass/fail and notes on site, for the three field users the RFP describes | BUILT |
| 6 | Automatic fee generation from record information | A fee engine computes from permit type and valuation at draft time. Amounts are placeholders: the city's posted fee-schedule link returned 404 when checked (2026-08-02); a deployment loads the adopted schedule as configuration in one sitting | BUILT |
| 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). A production deployment is a platform concern, not a build concern | PLATFORM |
| 8 | Integration of Medina County Auditor property data, auto-updating | Parcel lookup by PPN pre-fills property data and syncs into records; the feed is simulated and labeled. The real integration is a discovery item with the Auditor's office | SIMULATED |
| 9 | Customizable reporting, exportable to PDF, CSV, or Excel | The Reports tab: counts by status and type, fee position, activity log, one-click CSV of every record | BUILT |
| 10 | Migration of all data and documents from the current software | Not buildable without the incumbent's export. The plan below treats migration as its own phase with a parallel-run gate | PLANNED |
02 / Scaffolding vs configuration
What is reusable platform, and what is Medina.
The posting this exercise responds to pairs a forward-deployed PM with a forward-deployed engineer: the engineer owns reusable scaffolding for the product category, the PM configures it for the agency. The demo makes that boundary literal; every view carries a tag.
| Layer | Contents | Who owns it |
|---|---|---|
| SCAFFOLD | Record store and linking, workflow engine, fee engine, inspection scheduler, renewal clock, reporting and export, status tracker, parcel-lookup interface | The FDE; identical machinery serves the next city's permits, a county's septic program, or contractor licensing anywhere |
| CONFIG | Medina's 20-permit catalog (from the city's published forms page), the building form's actual fields (PPN, historic-district flag, improvement and use types, construction classes I-A through V-B, sub-permit links), the submittals-reviews-fees-inspections workflow order stated in the RFP, fee lines per type, inspector roster shape | The FDPM, with the agency, in days |
Time observed in this exercise: the scaffolding took roughly four times as long as the configuration. That ratio is the business case for the pairing model: the second agency pays only the configuration cost.
03 / Discovery questions
What the RFP does not answer, and I would not guess.
A working demo is not a deployment. These are the questions I would open discovery with, because the answers change the build and no public document contains them.
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; fee schedule and workflow captured as configuration; sample export from the incumbent | Director signs the workflow map and fee table |
| Configuration | 2-4 | Permit catalog, forms, fees, roles configured on the platform; staff walkthrough against real cases they choose | Staff complete five real record types end to end in the sandbox |
| Migration and parallel run | 4-8 | Full data migration; new applications enter both systems; discrepancies logged and burned down | One full week of parallel operation with zero unexplained discrepancies |
| Cutover and training | 8-10 | Public launch of online applications; counter-assisted mode live; field devices in use; incumbent goes read-only | First fully-online permit issued |
| Measurement | Through week 22 | 90-day scorecard against the baseline set in discovery, reviewed with the Director | Renewal decision on evidence, not inertia |
Timeline honesty: this assumes the incumbent can export and the Auditor feed has any machine-readable form. Discovery exists to test those assumptions in week one, not to discover them in week six.
05 / Cost structure
In the RFP's own three categories.
The RFP requests costs as initial setup, recurring, and miscellaneous. Real dollar figures belong to a real vendor's pricing and a real discovery; inventing them here would be theater. What an owner can hold me to is the structure and the unit lens:
| RFP category | What belongs in it | The honest unit lens |
|---|---|---|
| Initial setup | Discovery, configuration, data migration, training, counter-mode setup | Mostly the configuration weeks above; the scaffolding-to-configuration ratio in section 02 is what keeps this bounded |
| Recurring / annual | Platform subscription (seven users, three field), storage, support, fee-schedule and form updates | At the city's own stated volume, every $2,700 of annual cost equals one dollar per record. That is the number to negotiate with, because the city published it |
| Miscellaneous | Auditor-feed integration work, payment-processor fees on online payments, device hardware for field users | Each is a discovery line item with an owner and a yes/no, not a contingency bucket |
06 / Colophon
How this was made.
- Sources: the city's published RFP (volumes, requirements, process), its applications and permits page (the 20-type permit catalog), and its published Building Permit and Electrical Permit application PDFs (field structures, sub-permit cross-references). The posted fee-schedule link returned 404 on 2026-08-02, which is why fee amounts are labeled illustrative.
- Build: one working session on 2026-08-02, agentic tools end to end (Claude Code driving research, extraction, code, and browser verification). The demo is a single self-contained page with local-only persistence; the flows above were exercised programmatically in a real browser before this page was written.
- Process provenance: this concept survived an adversarial review that killed two earlier ones (a named audit of a city's public surfaces, and a document-only RFP response). The review's standard, that claims must survive the reader's own five-second check, is why every factual statement here cites a public document and everything simulated says so.
- What this does not claim: stakeholder discovery, which no artifact can perform; a production security posture; or the City of Medina's endorsement of anything on these pages.