Public Defender Case Management Software Problems: The 7 That Cost You Cases and Funding, and How to Avoid Them

Why does the conflict check keep getting scoped as a name search?

Because in a requirements meeting it sounds like one. Somebody says the system needs to check whether we have represented this person before, everyone nods, and a developer writes a search across a client table with fuzzy matching. The demonstration works. Production does not.

Name search fails in this domain for reasons that are specific to it. The same person appears under aliases and street names, under married and maiden names, under transliteration variants, and with three different dates of birth entered by three different agencies who each got it from a different source. Codefendant lists arrive as unstructured text inside a police referral rather than as a structured party list. And the conflict is often not with the client at all. It is with a listed witness who is a former client, with a complaining witness who is a current client, or with a family member in a related domestic matter filed under a different case number.

The fix is a person graph rather than a name index. People are entities with multiple identifiers, aliases and relationship edges: codefendant on, witness in, victim in, family of, represented by. A conflict check becomes a traversal from the parties on the offered case, and it returns the specific path that creates the concern rather than a list of similar names. Two design details decide whether it survives contact with a courtroom. It has to answer in seconds, because the attorney is standing at arraignment. And the determination has to be stored, not just the query, because the question that arrives later is what the office knew at the time of appointment.

What goes wrong when prior representation records are migrated?

The conflict graph is only as good as the history you can load into it, and that history usually sits in a system procured before anyone currently employed arrived. It typically has no unique person identifier, so the same client exists as eleven rows. It stores parties as free text on the case rather than as records. It carries no relationship information at all, so codefendants, witnesses and victims are indistinguishable from each other in the data even where the names are present.

Three failures follow. First, an automated merge on name and date of birth combines two people who are not the same person, which is the worst possible error in this system because it produces a false conflict that blocks representation, or worse, a false clear. Second, parties that were never captured leave silent holes in the graph, and a hole looks exactly like a clean check. Third, sealed, expunged and juvenile matters get loaded on the same footing as everything else and become visible to people who are not entitled to see them.

The fix is to migrate identity as a supervised process with a review queue, not a script. Set the automatic merge threshold conservatively and let a human resolve everything else. Mark migrated records so the system knows which parts of the graph are complete and which are best effort, and surface that on the conflict result, because an attorney needs to know the difference between no conflict found and no conflict found in the years we actually loaded. Apply access restrictions to sealed and juvenile records at migration time rather than as a later cleanup.

Why do jail and court integrations break after launch?

These two feeds change daily practice more than any feature on a roadmap, and they are also the parts most likely to quietly stop working three months after go live.

The jail feed carries custody status and facility. When it works, visit planning is routine and the client transferred to another county does not disappear for six weeks. When it drifts, nobody notices, because a stale custody record looks identical to a current one. The usual causes are unremarkable: the jail replaces its management system, a nightly export changes column order, an inmate identifier is reused, or a facility is added and never mapped. The court feed carries settings and docket events, and it fails when the court renumbers cases, adds an event type, or produces two records for the same setting after a continuance.

The fix is to treat both as untrusted inbound sources with schema validation and a blocking failure rather than a tolerant import. Add freshness monitoring so a feed that stops delivering raises an alert on the same day, since silence is the failure mode you cannot see. Keep the integration one directional wherever possible, consuming settings, dockets and custody status without publishing case content back. And handle identity at the boundary: a court case number and a jail booking number are not the same as your person record, and mapping them belongs in the graph rather than in a spreadsheet.

What happens when the wall around defense data is not designed in?

Your records are privileged. They cannot be visible to the court or the prosecutor even when everyone sits on the same county network, uses the same identity provider and is administered by the same IT department. That constraint eliminates a whole category of convenient integration, and offices that discover it late pay for it twice.

The failure is rarely dramatic. It looks like a shared county case management system that gives the court and the prosecutor a view of the same record because that was the point of the shared services agreement. It looks like a county database administrator with production access to defense case notes, who has never looked and should never have been able to. It looks like a backup routine that copies your data into a shared storage account. Nobody acts in bad faith and the exposure is real anyway.

The fix is architectural rather than a permissions setting. Separate data stores and separate access administration, with your own identity boundary even where the county provides single sign on. Administrative access to production limited to people bound by the same obligations as your attorneys, with every access logged. If your office runs a walled off conflicts unit, design for it, because checking a conflict requires seeing information the checking attorney may not be entitled to retain. Put all of this in the procurement document rather than in a later change request, because it is far easier to establish before a shared services agreement is signed than to unwind afterwards.

Should you build custom or configure what you already own?

If you are a single office of modest size with a manageable appointment volume and no assigned counsel administration, buy. Justice Works defenderData is built for exactly this population and knows the domain. Journal Technologies JustWare is a reasonable option, particularly where the court runs on the same family and integration would otherwise be painful. Karpel serves defense as well as prosecution offices and belongs in the comparison. At that size a build is money you would rather spend on investigators.

Build when you are a statewide commission or a multi office system. That is the strongest case, because the packaged products are designed around a single office, while a commission's actual job is measuring delivery across offices, panels and contract counsel in order to defend a budget, and that is the part treated most thinly. Build when conflict checking has already failed you, because a missed alias is a structural gap and no amount of process fixes it. Build when your caseload argument keeps losing because you cannot produce weighted data. And build when voucher administration is consuming a person full time, since that is usually the fastest measurable payback in the whole portfolio.

How do hidden costs get into the quote?

A first release covering appointments, the person graph with conflict checking, case records, structured client contact and calendar integration runs $110,000 to $250,000 over 14 to 20 weeks in our delivery experience. A full platform adding weighted caseload capture, assigned counsel vouchers with authorisations and approvals, investigator and expert requests, discovery receipt and commission reporting runs $280,000 to $650,000 over 9 to 18 months. The overruns come from a short and predictable list.

• Historical data quality. The conflict graph depends on prior representation records, and cleaning a legacy system with no person identifier is supervised human work in your office, not a script in theirs.
• Integration count and cooperation. Jail, court and financial system interfaces are each their own project, and the effort on the other side runs on the other side's calendar. A sheriff's IT team that is willing but unfunded is the most common schedule risk in this category.
• Multi office and panel administration. One office is a system. A commission covering many offices plus an assigned counsel panel adds administration, reporting and access layers that roughly change the shape of the build.
• Discovery at digital evidence scale. You receive the same gigabyte productions the prosecutor generates, and storage, ingestion and search for that volume is a separate line item that quotes routinely omit.
• Voucher payment integration with a county or state financial system, where the mapping is a negotiation with finance as much as a technical task.

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

Ask a prospective developer to design the conflict check in the first meeting. You want to hear a person graph with identity resolution across aliases and identifiers, relationship edges, and a result that returns the path creating the conflict. If they describe a name search with fuzzy matching, they will ship the thing you will regret.

Ask how they would capture attorney time without attorneys resenting it. The right answer is mostly passive capture from confirmed jail visits, calendar and docket derived appearances and document timestamps, with manual entry reserved for what has no other signal. Anyone proposing a billing style timesheet as the primary mechanism has never worked with a defender office and will deliver a system nobody fills in.

Ask directly how they will keep your data out of reach of the court, the prosecutor and county IT, and treat vagueness as disqualifying.

Sequence conflicts and appointments first, then client contact and caseload, then vouchers. Each stands alone and each produces something visible. It is also the right risk order, because a missed conflict carries professional consequences while a caseload reporting gap is a budget argument you can survive one more cycle without.

Settle ownership of the code, the repositories and the cloud accounts before kickoff. Digital Heroes transfers all three from the first commit. Privileged client data sitting in infrastructure you do not control, or controlled by a county department that also serves the prosecutor, is a problem you should never have to explain to bar counsel.