Domestic Violence Shelter Software Problems: The 7 That Cost You Funding and Trust, and How to Avoid Them

Why does the case management with permissions scope keep failing here?

Most developers arriving in this sector have built case management before, and the instinct is reasonable: a client record, service notes, a caseload view, and role based permissions to control who sees what. That design is adequate almost everywhere else and it is wrong here, because it treats confidentiality as an access question when it is a structural one.

Role based permissions answer whether a legal advocate can open the client screen. They do not answer whether the legal advocate should be able to learn that this person is currently in shelter, which is a different and more dangerous piece of information. They do not stop a caseload count from revealing occupancy. They do not stop an automated reminder email containing a client name from arriving on a phone that is not private. And they do not stop a well meaning staff member exporting a list to work on at home.

The fix is to design the walls into the model before any screens exist. One client record, with programme participation records attached, and access granted per programme rather than per role. Cross programme visibility requires a release of information that is itself a record with a scope, a date range and an expiry the system enforces. Then go through the side doors explicitly during design: what a notification may contain, what an export contains and who is told about it, what appears in a web address, and what search reveals when it finds nothing. A developer who has thought about this answers immediately and specifically.

What goes wrong when you migrate existing client records?

Most agencies arrive at a build carrying two versions of the same work: an identified record that advocates actually use, and a de identified extract assembled at report time. They were built by different people, at different times, from the same underlying reality, and they do not agree. Migrating both is how you carry the disagreement forward into a system that was supposed to end it.

The specific problems are consistent. The same survivor appears more than once because she returned after a gap and was entered again, and merging those records is a judgement call with safety implications rather than a deduplication script. Consent and release records frequently do not exist in structured form at all, so there is nothing to migrate that would justify cross programme visibility in the new system, and importing history without them creates access that no one has agreed to. Historical service entries were recorded against service definitions that have since changed, so counting them under current definitions produces numbers that will not match what you reported at the time.

What works is a deliberate line. Bring forward the people you are currently serving, with their programme participations, open safety plans, current consents and open referrals. Keep historical data in a read only archive with the same access controls, reportable in its original definitions. Then start the new reporting series from a stated date rather than backfilling, and tell your funders. Backfilled numbers that quietly disagree with previously submitted reports are a far bigger problem than a clean break.

Why do funder reporting exports break after they are built?

The report is built against the template your state administering agency published during the project, it passes, and then the template changes. A field is added, a service unit definition is tightened, an age band is split. The export still runs and still produces a file, and the file is now wrong in a way that only surfaces when a programme officer questions a figure.

The other recurring break is deduplication. When the same person receives shelter and legal advocacy, how they should be counted differs by funding stream and sometimes by report. Agencies handle this with a judgement made afresh each quarter by whoever assembles the report, which means the same underlying data yields different totals depending on who did it. That is not a reporting error so much as an absence of a defined rule.

The fixes are practical. Treat report definitions as configuration with an effective date, so a definition change is a versioned edit rather than a developer ticket, and so a report run last year still reproduces last year's numbers. Make the deduplication rule an explicit, named, documented rule in the system rather than an act of interpretation. And build lineage: every figure on a report must be traceable back to the constituent records by someone with the right access. When a funder queries a number, that lineage is the difference between an hour of work and rebuilding a quarter.

What happens when hotline and anonymous contacts are not properly covered?

Crisis line work is usually the largest volume of service an agency delivers and the worst captured. The reason is almost always the same design flaw: the system requires a client record before a service can be logged. Advocates faced with that requirement create phantom records, using placeholder names or initials, because they are on a call and need to record it.

That produces three problems at once. Your service counts become unreliable, because phantom records are inconsistently created and inconsistently reused. Your client population is polluted with entries that are not clients, which distorts every report built on it. And you have created identifying fragments about people who never consented to be in your system, which is precisely the outcome the confidentiality rules exist to prevent.

The fix is a contact log that stands on its own. It takes seconds, requires no client record, and captures call type, presenting issues, referrals given and duration while the advocate is still on the call. Anonymous is the default rather than an option. Where a contact later becomes a client and consent exists, the two can be linked, and that link is a deliberate act with a record rather than a side effect. The same thinking applies to unmet requests, which belong in the system without requiring you to create a client who is not one.

Should you build custom or configure what you already own?

If you are a single agency running one shelter and one advocacy programme, buy, and we would tell you that in a first meeting. Osnium is built specifically for this sector and understands the shape of victim services reporting. Apricot by Bonterra is a broader nonprofit case management platform with wide adoption and real configurability. Either costs a fraction of a build, and the difference is better spent on advocates. A small custom project on the budget an agency of that size can realistically find will be worse than the product you already have.

Before commissioning anything, test whether your complaint is capability or configuration. A great deal of what agencies blame on their software is a service definition that was never set up to match the funder's, or an export nobody has revisited since the template changed. Both are fixable inside a configured product by someone who knows it, and the fix costs a fraction of a build.

The build case is real in three situations and thin outside them. A state coalition funding one system across member agencies, where one system serving fifteen agencies costs far less per agency than fifteen licences plus fifteen sets of workarounds. A large multi programme agency running shelter, transitional housing, legal advocacy, child services and a hotline, where the walls between programmes are structural rather than a permission. And an agency whose funder reporting has outgrown configuration, where the quarterly spreadsheet rebuild has become an institution with an owner and a calendar entry.

How do hidden costs get into the quote?

The first is report count. Each distinct funder format is real work, and agencies routinely list two and discover five once state overlays and private funders are counted. Ask for a per report figure and a named list, and ask what happens when a template changes after launch.

The second is security work, which should be deeper here than in most projects and is frequently quoted as one line. Encryption at rest and in transit, access logging, penetration testing before go live, and a rule that no real client data enters a development environment all cost time, and the last of those means someone has to build realistic synthetic data.

The third is accessibility and language. Your clients and your staff are not uniform, and a system that only works in English excludes people who need it. Translation, right to left support where relevant, and genuine screen reader compatibility are scope, not polish.

The fourth is offline capture if advocates work in courthouses and hospitals, which is real engineering rather than a setting. The fifth is multi agency deployment, where serving member agencies with different practices demands a level of configurability that is usually the largest single cost driver and is usually discovered after the first two agencies onboard.

What separates a build that works here from one that fails?

The report is derived from the records advocates create in the course of their work, with de identification applied at the reporting boundary rather than by keeping a parallel file. The moment a separate de identified dataset exists, you are back to two versions of the truth and a week of reconciliation every quarter.

Bed availability is modelled as a real constraint rather than a count. An advocate taking a hotline call at two in the morning needs to know whether a family of five with a dog can be accommodated tonight, and that depends on unit composition, household size, the gender of household members, accessibility needs and whether two households can safely be placed near one another. A number on a dashboard does not answer the question, so staff keep a whiteboard, and the whiteboard becomes the real system.

The confidentiality behaviour is trained, not just built. Staff need to understand why a notification contains no name, why an export is logged, and what a release of information actually authorises. Systems that are technically sound and behaviourally misunderstood get worked around by people acting in good faith under pressure.

And there is a documented answer, agreed with your counsel and your state coalition, for what happens when a subpoena or court order arrives, with the system able to support it. That is a legal question rather than a technical one, and a developer who says so while describing what the system must support is giving you the right answer.