there are some types of version control already out there which lawyers use, e.g., hummingbird dm. it's pretty lame and annoying to use which is why many lawyers i know just do what i describe above for version control.
so bottom line: yes, it'd be useful, but it would have to be very easy to use otherwise people would just use marginally more annoying but in some ways much easier to use (don't have to learn how to do something new) methods.
So the idea of source control is probably useful. The current state of the art? Maybe less so.
One of my good friends works at an office where the secretaries put everyones tasks in to outlook just so they can have the calendar pop up telling them which case to work on from one hour to the next. Developer task management tools are light years ahead of the law world.
1) Don't try and save time (or at least don't focus on that), lawyers charge by time spent, saving time looses them money.
2) Your product needs good OCR. Many times, documents, even electronic ones, are printed out on paper, delivered in boxes, then scanned back in...don't ask why, that's just the way the world works.
3) You'll need pretty robust searching, tagging and entity extraction and case management in your product.
4) Visualization doesn't hurt.
5) There's many kinds of law, pick one (patent law) and focus on it. While there's some crossover between different sub-disciplines, they're different enough that you kinda have to just support one to start with.
6) You'll want a very robust data index and retrieval system that can handle millions of documents at scale. "Lots of documents" is not in the 4 digit thousands, they have paralegals and newbie lawyers to go through that amount of stuff, "Lots of documents" is 20,000->2 or 3 million documents. It's at the larger number that you'll be providing real value. No matter how much time the firm wants to charge for this kind of research work, they can't charge infinity, so their coverage of the material will always just be some subset.
7) Learn about the kinds of pricing models that'll work for you clients. Surprisingly, most law firms don't want to buy software, they want to lease it for the length of the case.
8) Most lawyers have the computer skills of a 90 year old man. It can't be a super technical system.
But if you became quick enough that you could make a point of it to your clients, then presumably you could charge more per hour. Exaggerated example, but if you could say to your clients (and back it up with previous cases) that the work that other companies are quoting them a year to do will only take you six months, but you want 50% more per hour then that works out well for the both of you?
I found that the time saving messaging fell absolutely flat (we can cover the same number of documents x-times faster). The only message that resonated was the coverage messaging (we can cover more documents during the limited discovery period)...and then only with firms that were working cases that involved hundreds of thousands of documents -- too much for them to staff up on.
The case/document management aspect of it seems to be where the real interest level lies and if you can offer lots of capability for drawing connections between disparate groups of documents it could have some true value. A digital organizer capable of aiding connection building.
At least that's what I remember. We did a bit of research into the market before deciding not to chase it due to the level of funding we would need to get a product to market.
> 2) Your product needs good OCR. Many times, documents, even
> electronic ones, are printed out on paper, delivered in boxes, then
> scanned back in...don't ask why, that's just the way the world works.
I've heard of lawyers that refuse to send things in PDF (even if they are available in that format) because the receiving lawyers will just print them out and charge you for the printing costs (since you didn't send it to them on paper). I'm also to understand that sometimes this is due to systems that have scanning of paper documents as the only input method... (ugh).