Public Defender Case Management Software: Why the Conflict Check Has to Run Before You Accept

Why an indigent defense office is not a law firm with public funding

Commercial legal practice software assumes a firm chooses its clients, bills for its time, and manages a matter list it controls. A public defender office is the inverse of all three. You do not choose clients, a court appoints them, often at an arraignment where the attorney meets the client for the first time in a jail video booth. You do not bill anyone, but your time data determines whether the legislature believes your caseload claim. And the matter list arrives at a rate set by the prosecutor's filing decisions, which nobody consults you about.

Two consequences follow that no commercial product handles. The first is that the conflict check is the gate on accepting work, and it has to run fast, at arraignment, against a body of prior representation going back decades. The second is that caseload is not a count, it is a defensible measurement, because the ABA Ten Principles and the caseload standards that have followed them are the language your funding conversation happens in, and a raw case count is the weakest possible version of that argument.

Underneath both sits a data problem nobody outside the office appreciates. Your records are privileged. They cannot be visible to the court or the prosecutor even when everyone shares a county network, a county identity provider and a county IT department. That constraint eliminates a whole category of convenient integration and shapes the architecture from the first sprint.

Problem 1: the conflict check is a graph query, not a name search

An office is offered an appointment on a case with four codefendants. A conflict exists if the office currently represents or previously represented any codefendant, if a listed witness is a current or former client, if a complaining witness is a current client, and in many jurisdictions if a codefendant's interests are adverse in ways that will only become apparent later. Add related matters: the same client's other open cases, family members in a related domestic matter, a juvenile matter under a different identifier.

Most offices run this as a name search in their case system. Name search fails predictably. Aliases and street names, transliteration variants, married and maiden names, the same person entered with three different dates of birth by three different agencies, and a codefendant list that arrives as unstructured text in a police referral.

What a build should do is maintain a person graph with identity resolution 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 is then a traversal of that graph from the parties on the offered case, returning the specific path that creates the concern rather than a list of similar names. The answer has to come back in seconds because the attorney is standing in a courtroom.

Two design details matter here. Store the conflict determination, not just the check, because the question of what the office knew at the time of appointment is one that comes up later. And design for a walled off conflicts unit if your office runs one, since checking a conflict requires seeing information that the checking attorney may not be entitled to keep.

Problem 2: caseload is a weighted number and your budget depends on it

A capital case and a misdemeanour possession case are both one case. Everyone in the office knows they are not comparable. Everyone outside the office asks how many cases each attorney carries and draws a conclusion from the answer.

The caseload numbers still widely cited come from the National Advisory Commission work in the 1970s, and there has since been substantial national effort to update those standards using contemporary workload research. Whatever standard your jurisdiction adopts, the argument depends on data your office has to produce: case type mix, disposition stage, hours actually spent, and the proportion of cases that go to trial rather than resolving early.

That means time tracking, and time tracking in a defender office is a cultural problem before it is a technical one. Attorneys who did not enter public service to fill in timesheets will not use a system that feels like billing. The design answer is to capture as much as possible passively: a jail visit logged when the visit is scheduled and confirmed, a court appearance derived from the calendar and the docket, a document produced timestamped automatically. Then ask for manual entry only where there is no other signal, and make it take seconds. Offices that get this right can walk into a budget hearing with weighted caseload data. Offices that do not are arguing from anecdote against a spreadsheet.

Problem 3: assigned counsel vouchers are a billing system with a review workflow

Where the office conflicts out, or where volume exceeds capacity, cases go to private assigned counsel who submit vouchers. That is a payment operation with public money attached, and in most jurisdictions it runs on paper or PDFs emailed to an administrator who checks rates, caps, and whether the claimed hours are plausible, then routes for judicial approval where the statute requires it.

The failure modes are consistent across every jurisdiction we have looked at. Vouchers arrive months late, so the office's own budget forecasting is guesswork. Rate and cap rules are applied inconsistently because they live in a memo. Expert and investigator authorisations are granted verbally and then disputed at payment. And nobody can answer how much a case type actually costs when handled by assigned counsel, which is the number the commission needs to compare delivery models.

A build turns this into structured claims against an appointment: rates and caps as data with effective dates, prior authorisation for experts and investigators as a linked request and approval, automatic checks against the cap with an exception path rather than a rejection, judicial approval routing where required, and a payment file to the county or state financial system. The commission then gets cost per case type by delivery model without anyone assembling it by hand.

Problem 4: client contact is the evidence that representation happened

Clients in custody are hard to reach, move between facilities without notice, and are released or transferred in ways that break contact. The professional obligation to communicate does not bend for any of that, and in offices under scrutiny the contact record is precisely what gets examined.

Most offices record contact in case notes, which means the answer to how many clients have not been contacted since appointment is unavailable without reading every file. That is the wrong shape. Contact should be structured events with a type, a date, an outcome and a location, so the office can run the question that matters: which clients in custody have had no attorney contact in the last 30 days, and which of them have a setting coming up.

Custody status is the dependency. If the system knows which facility a client is in, updated from the jail feed rather than from memory, then visit planning becomes routine and the client who was quietly transferred to another county does not disappear for six weeks. This is unglamorous integration work and it changes daily practice more than any feature on a vendor's roadmap.

Problem 5: the wall between defense data and everyone else is architectural

Shared county systems are a standing risk for a defender office. A county case management system that gives the court and the prosecutor visibility into the same record is unacceptable, and a county IT administrator with database access to defense case notes is a problem even when nobody has ever looked.

Design for it deliberately. Separate data stores and separate access administration, with your own identity boundary even if the county provides single sign on. Any integration with court or jail systems should be one directional inbound wherever possible: you consume settings, custody status and docket events, and you publish nothing back except what the court is entitled to receive, such as an appearance or a filing. Administrative access to production data should be limited to people bound by the same obligations as the attorneys, and every access logged.

Say this explicitly in procurement documents. It is far easier to establish before a shared services agreement is signed than to unwind afterwards.

What this costs and how long it takes

From the justice sector work Digital Heroes has delivered, 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 and ships in 14 to 20 weeks. A full platform adding weighted caseload and time capture, assigned counsel vouchers with authorisations and approvals, investigator and expert request tracking, discovery receipt handling and commission reporting runs $280,000 to $650,000 over 9 to 18 months.

What moves the number: whether you are a single office or a statewide commission covering many offices and an assigned counsel panel, since the multi office case adds administration and reporting layers. The quality of your historical data, because the conflict graph is only as good as the prior representation records you can load, and those are often in a legacy system with no unique person identifier. Jail and court integrations, which are worth the cost and are never free. Voucher payment integration with the state or county financial system. And discovery receipt at digital evidence scale, because you are on the receiving end of the same gigabyte productions the prosecutor is generating.

The economical sequence is conflicts and appointments first, then contact and caseload, then vouchers. Each of those is useful standing alone.

Build versus buy: when defenderData, JustWare or Karpel is right

Buy if you are a single office of modest size with a manageable appointment volume and no assigned counsel administration. 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 is otherwise painful. Karpel serves defense as well as prosecution offices and is worth including in a comparison.

Build when you are a statewide commission or a multi office system. That is the strongest case, because the packaged products are built around a single office and the commission's actual job, which is measuring delivery across offices, panels and contract counsel to defend a budget, is exactly the part that gets weakest treatment.

Build when conflict checking is failing you. If you have discovered a conflict after appointment more than once because a name search missed an alias, that 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's full time, since that is usually the fastest measurable payback in the whole portfolio.

How to choose a developer for indigent defense systems

Ask them to design the conflict check in the first meeting. Listen for 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 something that misses the case you will regret.

Ask how they would capture attorney time without attorneys resenting it. The right answer is mostly passive capture from calendar, docket and document events, with manual entry as the exception. Anyone who proposes a timesheet as the primary mechanism has never worked with a defender office.

Ask directly how they will keep your data out of reach of the court, the prosecutor and county IT. You want separate stores, separate access administration, a one directional inbound integration pattern and full access logging. Vagueness here is disqualifying.

Ask what they have integrated: a jail management system for custody and movement, a court system for settings and dockets, a financial system for voucher payment. Each one changes daily practice, and each has its own failure modes that only appear in production.

Ask who owns the code, the repositories and the cloud accounts, and settle it before kickoff. Digital Heroes transfers all three to the client from the first commit. For a defender office the stakes are higher than commercial: privileged client data sitting in infrastructure you do not control is a problem you should never have to explain to a bar counsel.