Build vs Buy Homeless Services and HMIS Software

Why buying the system of record is not a close call

This category is unusual because the buy answer is close to absolute for one component and the build answer is strong for everything around it. Take the absolute part first.

HUD revises the HMIS data standards on a fiscal year cycle, with changes taking effect at the start of October. Every revision touches elements, response values, logic and export structure. Your system must produce the HUD comma separated value export exactly, because the annual performance report and the consolidated annual performance and evaluation report are uploaded and rejected if the file is wrong. The longitudinal system analysis submission is stricter again. Federal partner programmes add their own elements for runaway and homeless youth, projects for assistance in transition from homelessness, and veteran services.

Absorbing that every year, permanently, is the actual product a vendor sells. Bitfocus Clarity, WellSky Community Services and Eccovia ClientTrack each do it across hundreds of communities, so the cost is shared. A single continuum that builds its own becomes the sole maintainer of a codebase tracking an annual federal specification, and the person who understands it will eventually take another job. We build regulated systems for a living and we would still tell you not to build this one.

If your dissatisfaction is with your vendor rather than with the gaps around it, the correct move is a competitive procurement between Clarity, Community Services, ClientTrack and Apricot. That is a buying decision, not a building one.

What is genuinely worth building around it

The build case sits in everything the HMIS was never designed to do, which is most of what a continuum struggles with on a Tuesday night.

Coordinated entry is the clearest example. HUD deliberately leaves prioritisation design to the community, so yours was written by a committee, revised after an equity review, and probably moved away from a single vulnerability score toward something combining chronicity, health, time homeless and locally weighted factors. Vendor configuration fits the first version of that policy well: an assessment, a score, a queue, a referral. It fits the third version poorly, once you have case conferencing, tie breaking rules, population carve outs, unit level eligibility matching and governed overrides that an equity review will want to inspect.

Shelter operations is the second. HMIS records a stay after the fact. It does not run a front desk at nine in the evening with a queue in the lobby, holds and maintenance status on beds, and a family needing adjoining rooms. So shelters run whiteboards and spreadsheets, the enrolment is keyed the next morning, live availability across the continuum is fiction, and diversion decisions get made blind.

Third, victim service providers are prohibited from entering client level data into HMIS under the Violence Against Women Act confidentiality provision and must use a comparable database producing equivalent aggregate reporting. This is one of the strongest build cases in the sector precisely because the requirement is aggregate equivalence rather than full data standard implementation, so scope is genuinely contained.

Fourth, local funders. City and county contracts want outcomes by council district and service units under their own definitions of engagement, none of which map onto HUD categories, so somebody rebuilds three reports in a spreadsheet every month.

Real numbers for each path

A compliant HMIS replacement realistically sits at $400,000 to $900,000 plus a permanent annual obligation to absorb standards revisions, which is why we advise against it rather than quote it enthusiastically. Vendor licensing for a mid-sized continuum is a fraction of that and carries the maintenance.

A companion layer covering HMIS integration plus one or two high value modules, typically coordinated entry decision support and continuous data quality work queues, runs $60,000 to $150,000 across 10 to 16 weeks in our delivery experience. A fuller build adding bed and unit inventory, an offline outreach application, a warehouse and multi-funder reporting runs $180,000 to $400,000 over 6 to 12 months. A standalone comparable database for a victim service provider typically lands at $50,000 to $110,000.

What raises those numbers: your vendor's application programming interface, which varies considerably in coverage and in whether it permits write-back at all, and in the worst case forces scheduled exports instead of live integration. The number of partner agencies, since each brings a data sharing agreement and a consent posture. Offline outreach, which is real engineering rather than a mobile skin. And any ambition to include jail release, behavioural health or benefits data, where the legal agreements take longer than the code.

The constraints nobody mentions until month two

Funding eligibility is the first and it is specific to this sector. Your HMIS costs are grant funded, and continuum programme funds carry eligible activity rules. A custom build has to be structured so the expenditure fits an eligible cost category and survives a monitoring visit, which sometimes changes how the work is scoped, phased and invoiced. Have that conversation with your collaborative applicant and your HUD field office before you sign anything, because retrofitting an ineligible expenditure is not possible.

Second, the October cliff. Data standard changes land on a fixed date, and your vendor will be shipping updates in the weeks before it. Any integration you build reads fields that may change on that date. Plan releases so nothing critical goes live in September, and budget a small annual window each summer to absorb the revision on your side of the boundary.

Third, consent. Different providers hold different postures, and your system's access model has to follow your continuum's data sharing agreements rather than a single global role structure. Designing that properly takes workshops with governance, not an afternoon with a project manager.

Fourth, staff capacity. Continuums are thin, and the same three people who would specify the build are the people producing the annual performance report. Communities that try to build everything at once reliably ship nothing before the next reporting deadline consumes them.

Fifth, on the buy side, get your data out. Ask your vendor in writing what a full export contains, in what format, and at what cost, before renewal rather than during a transition. Communities routinely find that the export they assumed was a right is a professional services engagement, and the moment to discover that is not the week you decide to move.

Sixth, outreach hardware. An offline application still needs phones that hold a charge through a shift and staff who are issued them rather than using personal devices, which raises its own privacy questions. That is a small budget line and a real policy conversation, and it decides whether the software gets used at all.

A test that shows which gap you actually have

Take three questions to your next governance meeting and time the answers. How many beds are available across the continuum right now. Why is this specific household in this specific position on the by name list, under which version of the prioritisation policy. And how many open enrolments are more than ninety days old, by agency.

If all three are answered inside ten minutes from a screen, your vendor configuration is working and you should not build. If the first requires phone calls, you have a shelter operations gap. If the second requires someone to explain the committee's intent rather than show the rule, you have outgrown configuration. If the third produces a promise to run a report, your data quality process is an email chase and detection is happening months late.

Then ask one more, quietly. Ask your victim service provider what they currently do. If the answer is a spreadsheet, or that they do not report, you have both a compliance gap and a service gap, and it is the most contained project on this list.

How to move forward

Pick one module. The single most common failure in this sector is a build that tries to solve coordinated entry, shelter operations, outreach and reporting simultaneously with a lead agency team that has a reporting deadline. Choose the gap that hurts most, ship it, and let it earn the next phase.

Before that, settle three things on paper: which activity category funds the work, what your vendor's interface will and will not permit, and how consent and data sharing agreements translate into access rules. Those three answers shape the architecture more than any feature list.

When you interview developers, ask whether you should replace your HMIS. Anyone who says yes without raising the annual standards cycle is either uninformed or selling, and both are expensive. Then ask what they did when a vendor interface did not expose a needed field, and listen for scheduled exports, reconciliation and a documented divergence report rather than a claim that everything synchronises perfectly.

Digital Heroes builds companion systems for public and nonprofit programmes, and every engagement starts with a written product requirements document before any code, which in this sector gives your governance body and your funder something reviewable before money is committed. The team is 50-plus people across 2,000-plus delivered projects, contracting through Indian, United States and United Kingdom entities so IP assignment sits with the lead agency under its own law, which matters because continuum leadership rotates and the system has to survive that. The Digital Marketing Heroes channel and its 2.5 million subscribers is a straightforward way to judge how the team explains decisions before you commit. Send your vendor, your agency count and the one gap that hurts most.

If you want a second opinion before signing anything, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You keep the specification either way.