Prosecutor Case Management Software Problems: The 7 That Lose Cases, and How to Avoid Them

Why does the scope keep getting written as a document store with a courthouse logo?

The requirements document for a prosecutor system is usually assembled from what staff currently do. Staff open files, attach documents, write notes and set reminders, so the specification describes a better file cabinet: a case object, attachments, notes, a calendar and permissions. Everyone recognises it, everyone signs it off, and it is the wrong system.

An office does not carry risk on its filing. It carries risk on two spines. The first is disclosure, defined by Brady v. Maryland and Giglio v. United States, which reaches material held by the wider prosecution team including agencies that never send you their whole file. The second is the clock, where speedy trial is arithmetic over a timeline of continuances, motions and unavailability, and every entry has to be classified when it happens. Neither is a document. Both are records that have to survive being questioned.

The correction is to write the specification from the two spines outward. Model the discovery production and the case timeline first, then let intake, charging, plea and disposition hang off them. Everything else in the office is downstream of those two, and a system that models them well is worth building even if it never replaces the case file you already have.

What goes wrong when you migrate legacy case files and digital evidence?

Two migrations happen at once here and they behave completely differently. The structured case data, parties, charges, settings and dispositions, is usually extractable and usually dirty in known ways: charging codes that were reused for different offences over the years, party records duplicated because a defendant was entered afresh on each new matter, and disposition values that meant one thing before a statute changed and another after. That is real work and it is knowable work.

The evidence is the problem nobody sizes correctly. A routine impaired driving case now carries several camera angles plus booking video. A homicide carries phone extractions measured in gigabytes and surveillance from a dozen private cameras. Offices assume moving it is a copy operation. It is a throughput problem, and the practical constraint is usually the network path between the agency's evidence platform and wherever you are putting it, not the storage bill.

The approach that works is to separate custody of the bytes from custody of the record. Keep the item level record in your system from day one: what it is, its fingerprint, where it lives, what protective order terms attach and what has been disclosed to whom. Let the bytes stay where they are for historic matters, and migrate wholesale only for open cases heading to trial. Charging codes deserve their own workstream before anything is loaded.

Why do the law enforcement and court integrations break after launch?

A prosecutor's office is downstream of everyone and upstream of almost nothing. Referrals come from police agencies on different records systems, video from evidence platforms you do not control, lab results on the lab's schedule, custody status from the jail and settings from the court.

Integrations here fail for a reason that is specific to public safety: the upstream systems are upgraded on their own budgets and their own timetables, and nobody tells you. An agency moves to a new records product, the export format shifts, and the feed does not error. It goes quiet. Referrals stop arriving and the first person to notice is a detective asking why a case was never filed, three weeks later.

The design that survives this assumes every feed will break, arrive late, or change shape without notice. That means durable ingestion with a visible queue rather than a silent job, reconciliation reports that show what you expected against what arrived, and a liveness alert per agency so a quiet feed raises itself rather than waiting to be discovered. Build the manual path deliberately as well, because the small agency sending you a monthly handful is never going to build an interface, and a system that only works for the two large agencies pushes everything else back onto paper.

What happens when officer disclosure and victim notification are left as manual duties?

These two gaps produce the situations that end up in front of a judge or a reporter, and both are usually outside the software scope because both are currently handled by a person who is good at their job.

Officer credibility disclosure is the sharper one. Most offices maintain a list of officers with sustained findings. In most offices that list is a spreadsheet held by one supervisor and it is not checked against witness lists automatically. The obligation therefore depends on someone remembering, and it fails on exactly the cases where everyone is busiest. Wiring the check into case preparation, so adding an officer as a witness immediately surfaces any disclosure obligation and records who was notified, is one of the highest value features available in this category and one of the least commonly built.

Victim notification fails the same way. State victim rights provisions, including the Marsy's Law amendments adopted in a number of states, create enforceable rights to notice and to be heard. When notification is a task someone remembers before each setting, it is the first thing to fall off a heavy calendar, and the failure is visible in a way few software failures are: a victim learns from the news that a plea was entered.

Both are fixed by generating obligations from the calendar rather than from memory. Every setting creates notification obligations for entitled parties, tracked across channels with delivery evidence and a fallback path, and contact preferences and safety restrictions live on the party record because some victims cannot be safely contacted at a home address.

Should you build custom or configure PROSECUTORbyKarpel or eProsecutor instead?

A large share of offices reading this should configure rather than build, and we would say so to a board of county commissioners. PROSECUTORbyKarpel is deeply embedded in this market and encodes a great deal of prosecutorial workflow that a new build would spend a year rediscovering. Journal Technologies eProsecutor is a serious option, particularly where your court runs on the same family of systems and the integration comes with it. Tyler Technologies is worth evaluating where an existing county estate makes integration the deciding factor.

If you are a small to mid size office with a stable process and moderate volume, configure one of these and spend the difference on staff. Replacing a working system because its interface feels dated is a poor use of public money and the transition cost alone will exceed the irritation it removes.

The build case is narrower and it is specific. Build when digital evidence volume has outgrown what the product handles natively, so the tool links to an external platform and you carry the certification risk with no record of your own. Build when your state's speedy trial construction is computed incorrectly, which is common because the rules differ substantially between states. Build the surround rather than the core when the core is fine: a discovery package engine, a notification service or a charging analytics layer can sit alongside an existing product. And build when the office is under a consent decree or legislative scrutiny about disclosure, because the requirement then is provable process, which configuration cannot promise.

How do hidden costs get into a prosecutor system quote?

The number of referring agencies is the first, and it is usually undercounted because offices think in terms of the two or three that send most of the volume. Each records system is a distinct interface with its own quirks and its own information technology department that answers in weeks, so ten agencies is not slightly more work than three.

Digital evidence is the second and it is the one that surprises people. Transfer throughput, retry behaviour and redaction workflow all behave differently at gigabyte scale than at document scale, and redaction in particular is an operational cost as much as an engineering one, because someone has to do it and the tooling determines how long it takes per hour of video.

Criminal justice information security requirements are the third. They affect authentication, audit logging, hosting and who may administer the systems, and they belong in the first architecture conversation, because retrofitting access controls into an application built without them is a rewrite.

Then the quiet ones: charging code cleanup, which is attorney time rather than developer time, and court integration for settings and dispositions, whose cost depends entirely on what the court will expose. Ask any developer to price agency interfaces individually, because a quote that treats them as a single line has not been thought through.

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

The builds that work start with discovery and the timeline rather than with case management. Both carry nearly all the office's real risk, both can be delivered alongside your existing product without a replacement decision, and both produce something a chief deputy notices in the first month. Full replacement becomes a much easier conversation once those two are running, and sometimes it stops being necessary.

The second marker is that classification happens at entry. Excludable time is recorded when the event is entered, with the authority attached, not derived later from minute orders. Any team proposing to compute it retrospectively has not sat with a trial attorney, and the system they build will produce a number nobody will stand behind in a hearing.

The third is that the discovery production is immutable. A production is a fixed set of items with content fingerprints, a generated index, a named recipient, a timestamp and an acknowledgement, and supplemental productions reference their predecessors so the cumulative picture reconstructs. If a developer describes discovery as a folder with permissions, they do not understand what the office is buying.

Finally, settle ownership before kickoff. The office should own the repository, the cloud accounts and the right to engage another firm. At Digital Heroes the client owns all three from the first commit. For a prosecutor this is directly a disclosure question, because the system holds the record that proves your compliance, and producing that record must never depend on a vendor's cooperation or a renewal negotiation.