Built by a litigator, for the platform litigators actually need

I have been in the legal industry for twenty five years. Most of that time has been on the trial side of civil litigation in California — plaintiff and defense, solo and team, simple matters and complex ones. I have used every major legal technology platform at some point along the way. I have lost work to the limitations of those platforms more times than I can count, and I have built workarounds for those limitations more times than I can count after that.

This article is about what I think the existing platforms get wrong, what they get wrong because of who built them, and what I built differently because of what I learned along the way.

The structural gap between vendors and users

The dominant legal technology platforms in the U.S. were built by founders and product teams whose primary expertise is software, not law. A few of the founders are lawyers; most are not. The product managers, the engineering leadership, the design teams — these are people with backgrounds in technology product development. Some of them have law firms among their customers. Some have done customer research at law firms. Very few have actually tried a case.

This is not a criticism of those teams. They have built impressive products. But it produces a structural gap between what the products do well and what trial work actually requires. The products tend to be excellent at the parts of running a law firm that look like running any small business: client intake, calendaring, time tracking, billing, document storage. These are the parts software people understand because they are universal small-business problems with a legal flavor.

The products tend to be less good at the parts of practicing law that are specifically legal: drafting that has to comply with a particular court's local rules, deposition analysis that has to support trial impeachment, discovery handling that has to survive a privilege challenge, motion practice that has to anticipate a particular judge's standing orders. These parts require domain expertise that most software teams don't have and can't easily acquire by interviewing customers.

The result is a market in which the legal tech category is dominated by products that handle the business operations of a law firm well and the substantive legal work less well. Practice management is the killer feature. Litigation is the gap.

What I noticed as a user

Over twenty-five years of using these platforms, I noticed a pattern in what I had to leave the platform to do.

The platform would calendar a court date, but I would calendar the actual deadline chain — the meet-and-confer deadline, the response window, the reply window, the hearing date — in a separate spreadsheet, because the platform's deadline calculator either didn't know my jurisdiction or didn't know my court.

The platform would store documents, but I would organize my litigation documents in a separate folder structure on my own machine, because the platform's document organization didn't match how a litigator actually thinks about a case file.

The platform would generate invoices, but I would track time in a different tool because the time tracking inside the platform didn't capture the granularity I needed for the kind of detail my clients wanted to see.

The platform would offer "research integrations," but I would use Westlaw or Lexis directly because the integrations were thin, the results weren't current, and the workflow was awkward.

The platform would, in the last two years, offer an AI feature. I would use it for the easiest 20 percent of my drafting work and switch to ChatGPT or another general-purpose chatbot — or just do it manually — for the 80 percent that mattered. The platform's AI was built on the platform's data model, and the platform's data model wasn't built for litigation.

The cumulative effect was that I was running my litigation practice across the platform plus seven or eight other tools, with the platform serving as the operational backbone but not the substantive workspace. I was, I eventually realized, paying a great deal of money for the platform to be the place where the parts of my work that I didn't enjoy lived. The parts I did enjoy — the actual lawyering — lived elsewhere.

What I wanted

After enough years of this, I started writing down what I would want in a platform if I could have one.

I wanted a deadline engine that knew my courts. Not "California" as a setting, but San Diego Superior Court Dept. 73, with Judge Wesley's standing orders applied to my matter, with the meet-and-confer requirements specific to that department, with the motion timing chains computed under the actual procedural rules in effect on the day I was looking at the matter.

I wanted document organization that matched how I thought about a case. Not "documents" as a flat folder, but a litigation-shaped structure: pleadings, discovery (propounded, received, my responses, their responses, follow-ups), depositions (taken, defended, exhibits, summaries), expert reports (mine, theirs), correspondence (with client, with opposing counsel, with court), motions (in progress, filed, pending), evidence, trial preparation.

I wanted to be able to upload a deposition transcript and immediately have it broken down for impeachment use — page-line citations preserved, contradictions across witnesses flagged, themes tied to the case theory, an outline for cross-examination ready as a starting point.

I wanted to draft a motion and have the AI know the specific local rules of my court and the specific standing orders of my assigned judge. I wanted every citation it produced to be validated against current authority before I saw it. I wanted to know, looking at the draft, which paragraphs the AI was confident about and which it wasn't.

I wanted an audit log that I could produce if anyone ever challenged my work. Not because I expected to be challenged on routine matters, but because the audit log itself would make me work more carefully, knowing that it existed. And because, in an environment where AI sanctions cases were piling up, I wanted infrastructure that would let me prove what I had actually done.

I wanted these things integrated. Not seven products with API connections between them, but one platform where the deadline engine knew the matter, the document organization knew the matter, the AI knew the matter, and the audit log captured all of it in a single record.

I did not find this platform anywhere on the market. Every product I evaluated had some of these features. None had all of them. The vendors offering practice management didn't offer the litigation depth. The vendors offering AI didn't offer the workflow. The vendors offering eDiscovery were enterprise-priced and not built for everyday motion practice. The market was a constellation of half-solutions, each of which had to be assembled by the lawyer.

Why I built Discover Docket

Two years ago, I started building Discover Docket because the market was not going to produce the platform I wanted to use, and I had reached a point in my career where I had the time, capital, and conviction to build it myself.

The premise behind the platform was structural. I did not want to add features to an existing legal tech product. I wanted to start from a litigation-first data model and build outward — from the case, the court, the judge, the rules — rather than from the firm operations layer that the existing products started with.

The result is a platform where the substantive litigation work is the foundation, not an add-on. The deadline engine is part of the data model. The document organization is litigation-shaped. The AI is built around the case file and validated against current authority. The audit log is cryptographic and chained. The business operations layer — billing, calendaring, intake, client portal — is there too, because firms need those things, but the operations layer sits on top of the litigation layer rather than constituting it.

The other premise was ethical. I built Discover Docket in the wake of Mata v. Avianca, while the bar associations across the country were issuing AI guidance, while Park v. Kim and the cases after it were establishing what professional responsibility under AI looks like. I built DDEAS — the Discover Docket Ethical and Accountability Standards — to be the architecture I would want any AI I used to operate under. Not because I expected to be sanctioned, but because I wanted infrastructure that made the sanctions failure mode structurally impossible.

The platform I built is the platform I would want to be using as a litigator. I think there are a lot of other litigators who want the same thing. That is who Discover Docket is for.

What being a litigator-founder changes about the platform

There are a few decisions in the platform that I think a non-litigator founder would have made differently.

Local rules and standing orders are first-class objects. Every California Superior Court is a separate entity with its own rules. Every department within a Superior Court is a separate entity with its own standing orders. Federal districts have their own local rules, federal judges have their own standing orders. A non-litigator might think of these as configuration data. A litigator knows they are the procedural environment that determines whether a motion gets heard or returned.

The deadline engine is not optional. Every matter is computed under the actual procedural rules of the jurisdiction it sits in, with the local layer applied. The lawyer doesn't have to remember to enable deadline calculation; the deadlines are produced automatically and updated as the case progresses. A non-litigator might treat deadline calculation as a feature for litigators who want it. A litigator knows it is the table stakes of running a litigation practice.

Depositions are structured objects. A transcript uploaded into Discover Docket is not "a PDF in the documents folder." It is a deposition record with the witness, the date, the page-line citations, the exhibits, the structured content. A non-litigator might treat depositions as documents. A litigator knows they are entirely different operational objects.

Judges are entities. A judge in Discover Docket has prior rulings, standing orders, observed patterns. A non-litigator might think of judges as a calendar field. A litigator knows the judge is often the most important variable in the case.

These are not exotic design choices. They are the obvious choices for someone who has actually practiced under the conditions the platform is meant to serve. They look obvious in retrospect, and they look invisible in advance — which is why, in our reading, the legal tech market hasn't produced them. The features show up in the platform when the founder spent twenty-five years wanting them and never having them.

What I would tell other litigators

If you are a litigator using a stack of seven or eight tools, none of which were built for what you actually do, you are not the problem. The market is the problem. The market produced products for the firms that buy software, not for the lawyers who practice law. The mismatch is structural, not personal.

The market is starting to produce alternatives. Discover Docket is one of them; there will be others. The lawyers who recognize what they have been working around for years, and who position themselves to use the new infrastructure as it becomes available, will be the ones who get the most value from this technology cycle.

The platform you have been wanting may finally exist. It may not be the one your firm has subscribed to for the last decade. It may be the one built by someone who, like you, spent a career wishing they had it.

See what we built →

Read the DDEAS framework →