jedgardyson

Thank you for calling out my straw man!

For the public interest space: LegalServer [0], PDCMS [1] (NY only), Defender Data [2], Pika Systems [3], CaseBox [4] (notably open source and AGPL), among others.

[0] https://www.legalserver.org/ [1] http://www.nysda.org/?page=PDCMS [2] http://www.justiceworks.com/ [3] http://www.pikasoftware.com/ [4] https://www.casebox.org/

For the down the line court space the companies are much larger: Tyler Technologies [5], File&Serve Express [6], ImageSoft [7], among others.

[5] http://www.tylertech.com/solutions-products/courts-justice-s... [6] https://secure.fileandservexpress.com [7] http://www.imagesoftinc.com/

I have a large spreadsheet with what I think is almost every company in the space, but don't want to post them all here so as to not overwhelm.

I think this is a fair-ish representative cross section of the kind of stuff that is currently out there though.

I might still change the title.

The reasoning behind the current choice was that I personally find the specificity to be a bit more compelling even if it is intended only as a go-to-market strategy. When I used to pitch this to folks as "rebuild the public data infrastructure for the legal system" they would mostly roll their eyes at me.

Point is well taken though. Thanks.

Thanks for the feedback!

This makes a ton of sense. We are planning to have an API and make it easy for folks to import/export data as a top priority.

A few related questions: 1) Would you be comfortable with the product storing a replica of your text files for search and analytics purposes? 2) Are there any other services that you use regularly that would be great integrations (beyond Dropbox, Outlook, Gcal, etc)?

Thank you for your comment. It is spot on.

Like I alluded to in the comment above, this was the problem that originally captivated me about the space.

I was retrieving some documents from court and had to go there in person once, and then 3mo later, to get the job done. Started reading about standards, court data practices in all 50 states and was appaled by the absence of good tools and open standards to solve exactly the problem you mentioned.

I've wanted to be a public interest lawyer my whole life, but when I saw how terrible the tooling/public data infrastructure for it was I thought that if I could take a crack at solving this problem it would, for me, be a more meaningful contribution towards helping to improve the lives of the people those attorneys serve.

Thanks for the comment.

As I've mentioned in other replies we have been warned about the dangers of the procurement process and read a ton about it too. The first iteration of this idea was actually to try and sell to courts to create precisely the kinds of open systems and standards that you describe here. After spending some time (more than I care to admit) talking to people who sell to government, reading about procurement, and reading through RFPs we realized that it would be a ludicrous for the two of us to try and sell to a court.

So, we decided to try and work with PDs first because we saw a need and an opportunity to get to know the players in the space, become familiar with the data, and make sure that we could scratch their itches better than anyone else. Once we are able to do that we are hoping to get to a small court that will let us prove that we can provide software that creates the outcomes they care about (money saved, happy judges, happy lawyers, happy clerks, and better access to justice). Then we'll start to work with procurement.

Eventually, we would love to say that we are developing an open "standard" for handling legal data, but we think that should come later, once we've been able to build something that people care about and are willing to pay for.

This is 100% correct and something that we have considered. If you go and talk to IT managers, chief clerks, and chief judges it quickly becomes clear that the politics of these sales to court clients are tremendous obstacles to overcome. This is the main reason why we decided not to sell to courts first. Once we have a great product and happy user base then we'll take a crack at them.

Thanks for the comment!

First off, thank you very very much for your comments and feedback. This post is amazingly on point based on everything we have seen so far. A few points to elaborate:

-They are. The folks we are developing with use one of these. We are still trying to figure out how to pull the data out of it into a portable format of some sorts, but we haven't had the time to crack the nut yet. Thankfully, our current client has expressed a willingness to run their CRM system side-by-side with our product as we launch and develop. As it currently stands the value of their data falls dramatically over time because its just not easy to get to.

-We've identified a number of constituencies within law firms (clerks, attorneys, managers as broad classes) they all have different use cases and we are doing our best to consider each of them as we progress.

-Yes.

-We think a bit more paranoia about data storage is not necessarily a bad thing. I personally enjoy explaining how this stuff works to people (its not just lawyers, most people don't have a good understanding about how and where their data is stored online).

-Yes, this was one of our biggest struggles starting out. I've been doing the research for a lot longer than we have been coding and trust building has actually been the hardest thing we've had to do.

-Yup!

-We will keep this in mind. We are currently developing it as a responsive web app (so functional on both) but we will definitely keep our eyes open for ways to enrich the mobile experience.

-This is a fascinating and ambitious thought that I will save for later.

-Again, 100% spot on. The managers are the decision makers and what they care about is record keeping and compliance.

-Will do more of this as we continue development. We have it set up for the backend currently, but I can definitely see the value for end users of being able to export bits and pieces of the data as needed.

Thanks again

This is definitely a valid concern to have.

Based on our research we think the guts and functionality of the product are portable to other use cases in the legal system. We might have to tweak the data model a bit, but the guts of the application should stay the same.

Also, although the market for PDs is "small" in the grand scheme of startups we think there is still plenty of money in it to at least generate enough cash flow to start a company that builds this class of solutions for high volume legal practitioners.

Thanks for the questions:

1) Not much so far as I can extrapolate (IANAL though). The data is provided by the attorneys and they will be using this as a service. We will have to have some sort of uptime guarantees stipulated in our agreement as well as support, standardized backups and safety policy etc. I'm not going to lie and say that we have figure this all out already, but we are thinking about it.

2) Starting out it will come from the users themselves (hence the 'New Case' tab in the demo). Eventually, for municipalities that allow it (NYC criminal courts are not among them), we'd like to get our hands directly on the case starting documents (Accusatory instruments, rap sheets, etc) and have them be piped straight into the system.

This is 100% correct and agrees with our research. The mobile use case for PDs has a lot to do with them just being able to access their case files electronically from home, something that a lot of their in-house CRMs simply doesn't allow.

That being said, a lot of courts are starting to soften up on these standards. For instance, I've been an infrequent visitor to NYC criminal and family courts, and lots of judges already allow the use electronics in the court rooms and some attorneys even use an iPad as their primary reference (but not notetaking) device.

Getting an influential CJ/Clerk on our board sounds like a great idea a bit further down the line.

Thanks for the comment.

i) Data portability is a key feature for us. As the excellent comment above noted users have been burned by fairly complex and locked-down in house CRM systems so we are doing our absolute best to make sure that the data can be accessed and ported in an easy way. ii) This is an interesting idea, especially with regards to evidence, care to elaborate a bit more? Do you think there is room for something beyond the regular database to track these case features?

This is more an artifact of how our data is currently organized more than anything else. It's on the list of things to fix once the guts of the whole system are set up.

We track height and weight (as well as a few other characteristics of a persons physical appearance) to give attorneys more data points on how to distinguish two people who have different names. Who knows, it might also be relevant to a case someday.

Thanks for the comment.

This is an interesting idea and something my brother (who has done more IT support than me in the past) has been badgering me about for quite some time. Most likely we will end up hiring someone to help handle this full time once we have more than one client, but for the first go around I just plan to do it myself. (Do things that don't scale says the church of PG)

Thanks for the question!

We plan on charging firms on a per case basis.

Eventually we also plan to to sell to other customers, particularly courts and prosecutors, but we have to start somewhere and this is where we felt there was the biggest mismatch between need and current tech.

Both prosecutors and courts have more money than PDs (generally), but they are also much much harder markets to crack since they tend to be more directly integrated with the governments IT and contracting infrastructure.

Yup! This is the answer that we came to from our research. If we could save the defenders (or courts or prosecutors) even a small amount of time per case then we can generate enough value to charge them a $/per case fee. We're still honing in on what the exact sweetspot for the case fee is, but based on what other folks in the market are doing it seems to be somewhere between $2-10 depending on who and where the client is.