Public Housing Authority Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope keep getting written as replacing the system of record?

The single most common scoping error in this category is deciding that the answer to frustration with the incumbent is a new incumbent. Staff are irritated by the interface, leadership cannot get the report they want, and someone concludes the agency should build its own housing system. That is the most expensive version of a problem the agency does not have.

The compliance surface here is federally defined. Income exclusions, asset treatment, payment standards, utility allowance schedules, inspection protocols and the tenant data submission specification are all set outside your agency and revised on their own timetable. An agency that builds its own submission engine has taken on a permanent obligation with no upside, because it must ship a change on someone else's deadline, forever, with one development team.

What is genuinely broken is almost always the layer around the system of record. Inspectors scheduled from a paper calendar. Landlord communication by phone and mail. A waiting list purge that takes weeks and produces poor response. Leadership questions answered from spreadsheets. A local policy the board adopted that the product cannot represent, so staff handle it manually.

Write the scope from those symptoms. Keep a compliant system of record and build the layer. A layer covering inspection scheduling with mobile capture, a landlord portal, applicant self service and quality control reporting runs $110,000 to $250,000 and ships in 16 to 24 weeks in Digital Heroes delivery experience, which is a different conversation from replacing your core.

What goes wrong when you migrate tenant, waiting list and historic determination data?

Data conversion here is always larger than expected, and the reason is that it reveals the true state of historic files rather than the state everyone assumed. Three things break.

Household composition is the first. Members added and removed over years, relationships recorded inconsistently, and a person appearing under two identities because they were entered afresh after a move. Any portal or self service function will surface those duplicates to the household in a way the back office never did, which is how a data problem becomes a customer service problem on the first day of go live.

Waiting list data is the second, and it is nearly always stale. Addresses and phone numbers age faster than any other field you hold, and a list that has not been purged recently will produce very low response to anything you send it. Building a portal on top of a stale list makes the staleness visible without fixing it.

Historic determinations are the third and the most consequential. Migrating a stored rent figure is easy. Migrating the ability to explain how that figure was reached is not, because the incumbent frequently stores the answer without a durable record of the parameters and policy choices in force at the time.

The approach that works is to migrate current state fully, migrate historic determinations as immutable snapshots with whatever supporting detail exists rather than as recalculable records, and purge the waiting list before the portal opens rather than after. Budget for conversion as its own phase with its own acceptance criteria, and expect it to take longer than the interface work.

Why do the accounting, banking and submission integrations break after launch?

Four connections matter and they fail on different clocks: the general ledger receiving subsidy and payment postings, the banking file for housing assistance payments, the system of record taking whatever the layer collects, and the tenant data submission reaching HUD on the current specification.

Submission breaks most visibly, and it breaks because the specification and the submission path are both maintained outside your agency and have been modernised more than once. Confirm the current system and file specification with your field office rather than assuming last year's process still applies, and do that before design rather than at testing.

The accounting integration breaks more quietly. A chart of accounts change made by finance for an unrelated reason, or a new programme added mid year, and postings start landing in a suspense account nobody reviews until reconciliation. The fix is a reconciliation report that runs on a schedule and compares what the housing side believes it paid against what the ledger received, with an alert on any difference rather than a monthly discovery.

Banking files fail on rejects. A landlord changes bank details, the payment bounces, and unless the rejection is routed back to a named queue it becomes a phone call from a landlord three weeks later. Treat every outbound file as a round trip with an acknowledgement state, not as a send.

What happens when accessibility, language access and data protection are not covered?

These three are treated as finishing tasks in most procurements and all three are structural. Retrofitting any of them costs more than building them in, and two of them are obligations rather than preferences.

Accessibility is the first. Public facing pages for a public body carry obligations, and a portal built without them will need remediation that touches markup, focus handling, colour contrast and every form on the site. That is not a styling pass. Ask any developer for a specific answer on standards and testing method rather than a general assurance, and require testing with assistive technology rather than an automated scan alone.

Language access is the second, and a translation widget bolted onto a finished site is not an answer. Notices, form labels, error messages and any text your staff write into the system all need a path, and the reminder a tenant receives about an inspection has to arrive in a language they read or the inspection fails and the cost lands on your inspector's day.

Data protection is the third. This data includes social security numbers, full household composition and income detail. Encryption at rest and in transit, role based access, audit logging of who viewed which family record and retention aligned to your records schedule are baseline requirements. The audit log matters more than agencies expect, because the question that eventually gets asked is not whether the data was secure but who looked at a specific family's file and when.

Should you build custom or configure Yardi, MRI HAPPY, Emphasys Elite or Tenmast?

Most authorities should keep and configure what they have, and we would say so in front of a board of commissioners. Yardi Voyager with its housing authority modules and MRI Software's HAPPY come from strong property management platforms, which shows in accounting and portfolio depth. Emphasys Elite and Tenmast were built for housing authorities specifically and reflect that in workflow familiarity, which is why so many mid sized agencies run them. A small authority with a few hundred vouchers should not build anything at all. Buy, configure properly, and spend the money on staff.

The honest constraints are consistent and they are not defects. Local policy depth is the first, because your administrative plan contains choices that packaged products handle through workarounds. Change cadence is the second: when a notice lands you wait for a release and your compliance date does not wait with you. Reporting flexibility is the third, which is why almost every agency runs side spreadsheets.

Build the layer when those symptoms are costing real hours. Build more than a layer only in narrow circumstances: a large authority where the economics genuinely change, an agency with moving to work flexibility whose local policies diverge substantially from the standard model, or a consortium building once for several authorities. Scale or genuine policy divergence justifies it. Dissatisfaction with a vendor does not.

How do hidden costs get into a housing authority quote?

Programme count is the first and it is routinely undercounted. Public housing, vouchers, project based assistance, moving to work flexibility if you have it, and any local or state programme each bring their own rules, their own forms and their own reporting. An agency describing itself as running two programmes often turns out to run five once someone lists them.

Data conversion is the second, and it is the line most often priced as an afterthought. It is a phase with its own discovery, its own reconciliation and its own acceptance, and it is where the true state of your historic files becomes everyone's problem.

Accessibility and language access are the third. Both are real engineering and content work for a public body, not a checkbox, and both need testing rather than assertion.

Security review is the fourth. Data including social security numbers and full household composition attracts scrutiny, and the review is a scheduled event with lead time that most plans do not account for.

Then the ones that are not engineering at all: agreeing how your administrative plan translates into rules, obtaining a usable export from a vendor with no incentive to be quick, and parallel running through at least one full recertification cycle. Ask for those to be named in the schedule, because a plan that omits them is a plan that will slip.

What separates a housing authority build that works from one that fails?

The builds that work start with inspections and the landlord portal, the two areas where packaged products are thinnest and where staff time is most visibly consumed. Inspection scheduling in particular is a routing problem funded as a clerical one, so grouping visits geographically, sending reminders in the languages your population actually speaks, and giving inspectors an offline capable form saves labour immediately.

The second marker is reproducibility as a design requirement rather than a feature. Parameters that change often, meaning payment standards, utility allowance schedules and locally set policies from your administrative plan, live in dated tables your own staff maintain. Calculation logic is explicit and versioned so any past determination can be reproduced with the rules that applied on that date. Ask a prospective developer how they would reproduce a determination from two years ago, and treat a vague answer as disqualifying.

Finally, settle ownership before award. The authority should own the repository, the infrastructure accounts and the unrestricted right to engage another firm. At Digital Heroes the client owns the code from the first commit, and for a public agency spending federal funds that is the answer a board should expect, because the software supports an obligation that outlasts any vendor relationship.