Apply HN: Casepad – Better Databases for Public Defenders and Others
Problem: lawyers, judges, and clerks who work in high volume case environments (public defense, small claims, family, housing, prosecution) at the state and local level need databases to: (1) Get access to basic information about their cases (2) Fulfill their sometimes onerous compliance requirements (3) Run basic analytics on their caseloads (4) Schedule their work around court appearances, client availability, etc.
Existing tools don't deliver on these four points because: no mobile or web access, onerous amounts of time to generate simple compliance reports, a lack any sort of extensibility, no integration with basic office productivity tools, bad search/indexing, and no automation of the onerous data intake process.
Casepad: is an attempt to solve these issues. We have partnered with one of NYC's institutional defense providers to build a modern database service geared towards these needs. They've provided us with full access to their staff, introductions to other professionals, and some "seed" money to build an mvp.
About us: we're brothers. I'm a '14 college graduate who worked in NYC as a data analyst. My brother is studying CS in Rio de Janeiro, Brazil where we both grew up.
Why We're Applying: two main reasons. First, we could use the money. It would be great if my brother could afford to move to NY with me and we could both tackle this full time. Second, I think we would benefit from the mentorship that YC and its network have to provide. It would be great to learn more from folks who have built great tech businesses.
Prior Work: we've been writing code and interviewing users for Casepad for about 3mo now. Over 60 attorneys, judges, and clerks were interviewed while we validated some of our assumptions about the broader legal market.
If you have any questions, comments, feedback, or interest in the project reach out. We'd love to hear from you!
65 comments
[ 4.4 ms ] story [ 149 ms ] thread[1]: I'm making up the $10 number. No clue what pricing they'll be doing.
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.
Based on this discussion, I'd suggest that you deemphasize public defenders, at least removing it from your tagline. I'm sure there were others who had a similar reaction to me. Instead, pitch your service as one for the entire legal system, and then discuss how public defenders will be your go-to-market strategy.
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.
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?
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.
Or are you building indexing + collaboration on existing databases ? Kind of a collaborative LexisNexis ?
But to me this sounds more like bespoke software for a single client rather than a startup.
If you want to apply with this idea, you need to make sure there actually is a market for your software.
I've seen many people attempt a "startup" by writing software for free for one client, hoping to sell it to other clients with similar needs. These other clients then never materialised, since the software usually ended up too specific and was only useful for their original client, who got to use it for free (or very cheap).
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.
Maybe setting up some sort of volunteer customer support in, say, Slack could be the way forward? You could also implement a livechat integration that feeds into your public Slack team.
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)
- Your customers will be running a centralised practice management platform (basically a specialised CRM), you'll need to integrate with it; this isn't easy. In fact it's really hard.
- Most of the time, the fee-earner/practitioner won't do any of their own data input, they'll have their PA do it for them, consider this when you're building a backend.
- They live and die by their Outlook calendars and contacts. You'll need to integrate with that; this is easier.
- You'll have questions about how you're storing and transmitting data and what jurisdiction its being hosted in. Some of these questions will seem naive and obvious, but legal tech is a _paranoid_ market.
- This is also a CONSERVATIVE market, they fear change, they don't like change. This is a constant uphill battle.
- The flip side is that 90% of the software in this market is 5-10 years old and "cloud" solutions are novel and strange to them (cf fear about data storage)
- Focus on mobile. Ignore desktop. Seriously.
- Don't discount this only being applicable for lawyers, any professional service industry (financial planners etc) will benefit from this.
- You're right compliance, audit trails, history is EVERYTHING. Pitch it as a record keeping solution for the firm, not a productivity tool for the practitioner.
- Bake in export. Make the data as easy to get out and easy to get in.
-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 "our current client has expressed a willingness to run their CRM system side-by-side with our product as we launch and develop. " is really important, partner with a guinea pig firm so you can learn on the ground
- The flip side is that 90% of the software in this market is 5-10 years old and "cloud" solutions are novel and strange to them (cf fear about data storage)
Actually I'd have to disagree with that to some degree. I do agree there is some what of a stickyness for doing things the way you were doing things, but its also pretty regional. California is a very different audience then Indiana. Additionally more and more states are mandating the move digital products.
What? Do lawyers not use laptops, what with all the writing? Are they seriously spending their days typing with thumbs on glass? That seems insane.
2) Where do you get the data from, and how scalable are those sources (e.g. does it vary by municipality)?
Just want to echo others saying it's great to hear how many customer interviews you've done.
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.
You probably need strong use-cases that DON'T involve in-the-courthouse access. Or you need an influential chief judge or court-clerk department executive in some visible jurisdiction on your board of advisers.
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.
As a counterpoint, all the courts and jurisdictions I practice in permit attorneys to bring an electronic device into court. (Although may god have mercy on your soul if it should make a noise in court). Several have implemented e-filing and provide wifi in the courtroom for attorneys. One has laptops provided by the court on counsel tables to access the court's filing system and in another the prosecutors have computers in the courtrooms which are on their office's network. Come to think of it I can't think of ANY court I've been in the last 5 years which doesn't permit attorneys to bring in electronic devices. Non-attorneys -- yes, they are not allowed to bring in electronic devices.
My question is who are you selling this to? If it's just attorneys, that's fine. But if you want courts to adopt it, you will be competing thru a procurement process. This can be death for a startup - long timelines, complicated bidding procedures, and endless requests for customizations. There's huge amounts of money to be made, but by established players who are familiar with the process, built a basic CMS, and can spend thousands of hours of dev time customizing and installing it. Often for just one jurisdiction. Rinse and repeat for the rest of the country...
What I've proposed in the past is a "Wordpress for courts" - a free, open source case management system. It will be more quickly adopted by smaller courts with limited budgets. As larger court systems take notice, they will be attracted not just to the cost and better UX, but the extensibility. The country will benefit by having better, faster access to court records, case law, etc.
I've considered submitting it as a non-profit to HN. And you could easily create a for-profit based on implementation and customization services.
Me too.
>What I've proposed in the past is a "Wordpress for courts" - a free, open source case management system. It will be more quickly adopted by smaller courts with limited budgets. As larger court systems take notice, they will be attracted not just to the cost and better UX, but the extensibility. The country will benefit by having better, faster access to court records, case law, etc.
This. So much this. Courts are either buying commercial systems which are incredibly expensive and suck, or building their own which turns into a huge political football and results in a product that is ... what you expect. Someone (perhaps a 501c3 or something similar) needs to build a best in class open source court/case management system. Similar to what the 18F people are doing at the federal executive branch. There is still plenty of money for contractors/companies to make implementing and maintaining the solution for the individual courts, but every court in the country from the U.S. Court of Appeals to Mayberry Municipal Court running (or developing!) a different management system is insane.
Imagine if all the Courts had a common API to accept your filings or notify you of case activities?
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.
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.
Please definitely build a prototype around this and submit it to YC.
I can only speak to Massachusetts, and I can only speak to the time ~ mid 2000s when Rhode Island and Massachusetts were dealing with claims of racial profiling - specifically driving while black - but there was a great deal of friction with having a central store of any aggregate data on specific judges.
The idea that you could easily run an analysis of a judge's decisions cross referenced by, say, race, was such a complete non-starter in most professional judicial working groups where you'd be looking for buy-in on something like this. Having a good deal of these records available in disparate systems, or even better, only in paper form, was actually a concerted decision at that point in time.
I'm really interested to see what kind of traction you see (and where it comes from). Good luck!
Thanks for the comment!
Nice project. One comment (as a lawyer) - Have an API. So much legal software out there is a closed island. Maybe the developers think they can lock everyone into using their software for everything (calendar, document management, billing) by not providing an API, but it is infuriating. Chances are we might really like one part of your app (not you specifically, but legal software vendors), but other parts of it are mediocre at best and we don't want to use it. E.g. - all the case management software that also wants to be the datastore for our documents. Really? We already have dropbox, I seriously doubt you are better than them at storing documents in the cloud and syncing to local machines.
I've starting rejecting software at our firm if it 1) doesn't have an easy way to get all of our data out in a reasonable format and 2) doesn't have an API that plays nice with the other software we use.
We utilize full disk encryption on all of our machines and MDM type services which allow us to brick/erase a device remotely (now dropbox for business has a similar feature which will wipe a remote device if it connects to the server after such a request). We also force on dropbox's 2FA for all users and every access to a file by a user is logged.
Dropbox also gives us the ability to revert to any version of a file in the event a user makes an unwanted modification (a whoops or something like crypto-ransomware malware).
Obviously there are still risks in this type of setup, but most law firms I have seen have far far riskier setups that have far easier vulnerabilities to exploit if they were a target than Dropbox being compromised. (At least in my opinion).
EDIT: Also, I want to amplify that the information security skills and experience present at any major cloud provider (google, aws, dropbox, box, etc.) is in a totally different league than anything I have seen at even the huge MegaBigLawFirms. There are very few firms that take information security as seriously as they should and even those do not have the resources of the aforementioned companies. Essentially I trust google/dropbox to keep their digital stuff secure more than I would trust any law firm on the planet.
There is one exception to this -- which is some sort of sealed search warrant or national security type letter from a government agency. If there is information you are seeking to protect from an exploit in that realm, then they are certainly vulnerable in that area and you (the law firm) need to implement other precautions to address that vulnerability.
Regarding the exception you mention, what granularity would you make this distinction at? For example, would you typically just say that all files related to a particular case must be protected from a government agency, or would you divide up the storage of files for particular cases at a finer granularity (e.g. some files for this case can be stored on Dropbox).
If Dropbox offered a solution with client-side encryption, how much do you think you would be willing to pay for it in terms of cost or performance?
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)?
What are the existing tools and/or your competitors?
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.
How are you going to approach sales?
I think your intuition here is correct. Like a few other comments mentioned the buyers are very very conservative.
Our first step to sales will be to deliver on what we've promised to the firm that has taken a bet on us. The market is very trust driven, since the outcome of a criminal case can change a persons life, so we need to make sure that we can deliver on our promises above anything else. That being said, firms really want a solution to this problem. We have started talking to a few other firms in NYC who have a use case that is identical to the one we are building for so once the product is ready we'd hope to follow-up with a few more sales wins.
http://thomsonreuters.com/en/products-services/legal/large-l...
May be you could compete on price? Or what is your strategy?
The short answer is, I am not sure. We haven't really had the time to examine the demand/need for this type of service outside of the US.
The longer answer is that if we were to expand abroad the data model would need to be tweaked to adapt to each country/local jurisdictions' particular needs for compliance and automation. This is something that we will already have to do across different jurisdictions in the US and are accounting for as we build the software so, from a purely technical perspective, it should be feasible.
See the recent call by the US DOT for agencies to adopt and publish transit data using the GTFS data standards (originally developed by Google for streamlining consumption of transit data )from different agencies. http://gis.rita.dot.gov/Transit/downloads/DearColleague.pdf
BLDS Specification originally developed by Accela for building permits. Now many competitors are signing on and adopting the standard. http://permitdata.org/
Your point is well taken. We are committed to building transparently and with good standards.
We have looked at some existing legal documentation standards such as LegalXML[0] and are still in the process of evaluating whether or not we should implement them in our work. We are also open to developing additional standards as needed, but need to do a lot more research before we feel comfortable claiming the world needs yet another specification[1]. :)
[0] http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4...
[1] https://xkcd.com/927/