What changed
FACT: On 2026-06-18 HUD published a 30-Day Notice of Proposed Information Collection under HOTMA for a 'Public Housing Waiting List Data Collection Tool' — a mandatory, standardized waiting-list data submission from Public Housing Authorities to HUD (Federal Register 2026-12338). This is a new/formalized recurring reporting obligation on PHAs.
Why now
FACT: The notice is a 30-day OMB-approval step, meaning the collection is imminent and PHAs will soon face a standardized submission format they currently don't produce. INFERENCE: PHAs keep waiting-list data in a patchwork of legacy housing-management systems, spreadsheets, and paper — normalizing it to a new HUD schema is exactly the kind of one-time-per-period pain a tool removes.
Converging signals
FACT: A HUD rule (HOTMA), a defined forced-filer class (PHAs administering public housing waiting lists), and a HUD portal/tool converge at one submission. INFERENCE: The surrounding demand_evidence shows HUD is simultaneously pushing many PHA-facing collections (MTW plan/report, tenant education, grant financial reporting), indicating a broader PHA compliance-tooling surface to expand into.
Customer pain
INFERENCE: PHAs have small back-office staffs and must reformat heterogeneous applicant data to a new federal schema under deadline; getting it wrong risks HUD findings. FACT: The source text does not state a per-PHA burden-hour figure, so the exact staff cost is unquantified here (hypothesis).
Who pays
FACT (class): Public Housing Authorities administering public housing waiting lists. INFERENCE: ~3,000+ PHAs nationally (the PIE figure is explicitly marked inference in the input, not a HUD-stated count); realistic near-term buyers are the several hundred mid-size PHAs too big for manual reformatting and too small to have IT staff.
Solved today
INFERENCE: In-house staff hand-exporting from housing-management systems (Yardi, Emphasys/Elite, Tenmast/MRI, HAB) into whatever format HUD requests, or leaning on their HMS vendor to add the export. No cited incumbent tool exists in the source.
Why current solutions are bad
INFERENCE: Manual reformatting is error-prone and repeats every reporting cycle; HMS vendors are slow to build low-revenue compliance exports and charge change-order fees. Hypothesis pending confirmation of the exact schema.
Proposed product
A web tool where a PHA uploads its raw waiting-list/applicant export (CSV/Excel or a mapped HMS extract), the tool validates and normalizes it to the HUD HOTMA schema, flags missing/invalid fields, and generates the exact submission file/package HUD's collection tool accepts. Per-seat subscription per PHA plus optional per-submission assist.
MVP version
A single-tenant uploader + schema validator: define the HUD field spec, build CSV/XLSX → HUD-format mapping with validation errors, output a submission-ready file and a QA checklist. No portal auto-submission until the exact HUD system/API is known.
30-day build
Read the full ICR supporting statement + draft data spec from the Federal Register docket and regulations.gov; file a public comment (free credibility + direct line to the exact fields). Interview 8-12 PHA compliance/occupancy staff (NAHRO/PHADA member directories) to confirm current workflow and willingness to pay. Build the field spec.
60-day build
Ship the validator/normalizer MVP against the confirmed spec; onboard 3-5 design-partner PHAs at a discount; add mappings for the top 2-3 HMS exports (Yardi, Emphasys, Tenmast).
90-day revenue plan
Convert design partners to paid annual seats; outbound to state PHA associations and mid-size PHAs; target first $2-5k MRR. Add the actual HUD submission/upload step once the collection tool's format is finalized.
Distribution path
Direct outreach via PHA associations (NAHRO, PHADA, state chapters), the public-comment thread, and HMS-agnostic positioning ('works with any system'). Webinars aimed at occupancy/compliance directors; demonstrated value, not relationship sales.
Pricing hypothesis
Per-PHA annual seat $600-1,800/yr scaled to PHA size (unit count), plus optional $150-300 per-submission concierge for the first cycle.
Technical difficulty
Low-to-moderate: data normalization/validation is squarely in the founder's wheelhouse. Main unknown is the exact HUD schema and whether submission is a file upload or an API — resolvable from the docket.
Legal / regulatory risk
Low. Handles PHA-held applicant PII (names, income, household data) so needs sane data handling, but the founder isn't the regulated party — compliance is the moat, not a licensing burden.
Platform dependency
None deplatformable — the counterparty is HUD, a government system. Only dependency risk is a HUD-provided tool/portal that fully automates formatting itself (see kill args).
Founder fit
Very high — this is the exact government-portal forced-filer shape he already monetized with FMCSA ELDT: read a federal mandate, identify the compelled filer class, build the submission/normalization layer, charge per seat/filing.
Breakout potential
Moderate-to-high: 3,000+ near-identical buyers and an adjacent stack of PHA-facing HUD collections (MTW, tenant education, grant financial reporting all in the evidence) to expand into — a 'HUD compliance filing' suite.
Final recommendation
PURSUE-BUT-VALIDATE: high founder-fit and a clean forced-buyer shape, but gate the build on reading the ICR supporting statement to confirm (a) the exact schema and (b) that HUD's tool does NOT already self-serve the formatting. If both check out, build; if HUD ships a full self-service form, pivot to the HMS-export-mapping and QA-audit angle.
Next action
Pull the full ICR supporting statement and draft data-spec from regulations.gov / the FR docket (2026-12338) to confirm the required fields and whether HUD's tool auto-formats; simultaneously email 8-12 PHA occupancy directors to confirm the manual pain and price tolerance.