Legal Tech -- Behind the Tech: Client-Centric Innovation: The Evolution of the Casepoint Platform

At the time, I am not sure anyone viewed the lack of end-to-end e-discovery as a core problem, and I don't recall getting any feedback from clients that addressed that issue directly. I did, however, get an up-close view of our clients' pain points in dealing with a multi-app workflow. These pain points included:

• Constant data movements from one application/platform to another. As we all now know, data movements consume time and money, and they significantly reduce efficiency. Apart from compatibility issues, data movements also increase the risk of data loss and spoliation.
• A lack of simple, transparent pricing for the various tools vendors were offering. Firms and law departments were typically charged for basic technology tools individually as line items, and found that it was difficult to access new features that promised better performance from their software applications. All-inclusive pricing was pretty much unheard of at the time.
• Inefficient and disjointed workflows requiring that users learn to interact with multiple interfaces, and log in to and out of applications repeatedly.

In seeing clients' pain-points and becoming intimately engaged with their internal processes, my colleagues and I resolved to address a problem that many of our clients may not have even known they could fix. At Casepoint, we had already begun working on advanced tools for specific e-discovery workflows such as early case assessment (ECA) and technology-assisted review (TAR), but our overriding goal from the outset was to fill the efficiency void that was so obvious in all of the feedback we were receiving from clients across the board by developing a fully integrated, end-to-end legal workflow platform. Clients wanted a platform that was flexible — so they could adapt it to their own requirements and their own way of doing things — and scalable, so it would be practical and economical for organizations of all sizes.

Don't Just Build It, Build It In: The Examples of ECA and TAR

At the time, many people were using ECA technology, but they were doing so with a collection of discrete tools. They had to keep moving data out of one application and putting it into another application, and then back again into the first application. Clients complained the process was clunky and costly, and it was. For example, they would have to export data out of Relativity, upload it into Content Analyst, run ECA, then export what they needed out, and import it again into Relativity. (Not surprisingly, Relativity eventually acquired Content Analyst.) Incredibly, many people in the industry are still following this same process. The inefficiencies take up extra time and create extra costs, and they introduce data management issues as well. That's one reason why we began to work on a seamless workflow platform with ECA built-in.

A similar story played out with TAR. Many firms were using third-party tools which required they load data to an application, run TAR, then export the data to their review tool. It's obvious that moving data from one system to another system is inefficient and expensive. Clients also complained that TAR vendors typically charged by the document. It occurred to us that hefty per-document fees were actually discouraging people from using a technology that was very powerful and effective. Again, as we worked closely with our clients and began to see things from their point of view, it was clear that there was frustration in the marketplace with the way TAR was being offered, and there was a huge opportunity if you could make it really fast, eliminate or dramatically reduce the need to move data from one application to another, and make the technology available as an integral part of the e-discovery toolset under a single price point — rather than charging extra for TAR, which was standard at the time.

All of this emerged from our realization that we needed to think of our company and our platform as an extension of our clients. This sounds like a common sense approach, but in the legal technology space many vendors, especially companies that rely on VC funding, are under a lot of pressure to prioritize short-term profits over long-term relationships.

Use Customer Input to Inform Product Development and Drive Innovation

Our adoption of a SaaS-based model is another example of client-centric development. Many of our customers were intrigued by cloud computing, but some were quite skeptical, especially for security reasons, about adopting public clouds like AWS or Azure. Cloud architecture was still relatively new and regarded with caution. Our response was to build our own private cloud infrastructure to serve as a SaaS solution for our customers. Clients wanted us to take responsibility for the security of their data, and this gave us complete control and allowed us to meet that requirement. Also, it would have been difficult to move terabytes of data around any other way, because doing so requires a lot of bandwidth. From storage to processing to hosting, from the server to data, clients were able to trust that their data was safe because we own the hardware and the infrastructure, and this also gives us a lot of flexibility. Developing a SaaS solution has been a crucial chapter in our evolution, because it allows us to own the responsibility of security and to assure our customers that they don't have to worry about it themselves.

Another specific pain point for e-discovery practitioners over the last decade was the fact that all the review tools in market, including ours, relied on plug-ins to allow users to view native files. The plug-ins were necessary to be able to work with all browsers and systems. This meant that they had to be tested and verified. Also, because most firms have a lot of firewall and security measures, we encountered significant issues deploying plug-ins. We also had to update plug-ins as new file formats came in, and it was inefficient and impractical to meet customer requirements for each user's desktop.

Customers complained that document loading was slow, and they were right because the system needed to download those files locally and store them, then display them using a locally installed plug-in. We finally concluded that plug-ins were not scalable or sustainable. To eliminate all this complexity, we came up with a native file viewer which is browser-agnostic. No plug-in deployments are necessary and all the latest browsers are supported. Again, it was our client-centric perspective and our close work with individual customers that led us to develop this solution.

I am sometimes asked why the deployment environment of our recently released platform is built on Web API and N+1 scalable architecture. Why is that important? The answer is that it gives us tremendous flexibility to respond and adapt to client needs. It allows us to scale up our infrastructure rapidly without any changes from front end. If clients require additional scale, all that's necessary is to deploy more servers, and then we're set to go with a larger infrastructure, without negatively impacting our end-users. Clients come to us with unique technical and business requirements and this architecture gives us the flexibility to deftly and creatively build virtually any infrastructure. Sometimes clients need dedicated resources. With other clients, it makes more sense for them to share resources using a multi-tenant system. In either case, the platform can scale easily and rapidly.

The Web API interface simplifies our internal development stack, not only for rapid development but also for rapid deployment as distributed services to create an efficient, high-performance system. Based on our conversations with customers and our ongoing analysis of the marketplace, we have decided our growth is tied to developing cloud-friendly technology and maintaining future cloud infrastructure adaptability. We have innovative technology compatible with the private or public cloud, and this will allow our customers to excel and our business to thrive well into the future.

Provide Fewer, Simpler Tools That Are Accessible to Ordinary Practitioners

There have been many technology innovations over the past 20 years or so that have transformed e-discovery, including ECA, native review, TAR, artificial intelligence and more. However, none of these innovations can be truly ground breaking if they remain discrete tools, each of which have to be learned by users and incorporated into disjointed workflows that rely on many other point tools. To become transformative, the innovations must be easily learned and adopted by users without advanced technical skills. We need tools that are intuitive and user-friendly, but we also need to dramatically reduce the number of different tools legal professionals have to use in order to do their work. That's why integration is so important now.

If you have a platform that can be used from collection to production, but also, with the help of AI, run analytics on multiple matters at a firm so you can predict trends in future litigation — that's innovative. Are you able to use that same platform for data management and invoicing? That's also innovative. Innovation is only as good as its accessibility to the everyday practitioner.

To fully realize this vision of accessible and fully integrated technology, vendors need to build a culture of innovation in their organizations based on a client-centric philosophy whose focus is on creating a compelling value proposition for all. We need to take client feedback to heart and constantly incorporate that information into our product development processes. Today's clients want to be able to initiate new projects and develop new customizations on their own using the platform we provide, and they want to be able to do these things quickly. That's the direction of the marketplace, I think, and vendors who want to still be in business 10 years from now should take note.

As the CTO of a legal technology company, I am excited by the changes I am seeing in the marketplace today. I find it refreshing to watch as more legal professionals adopt technologies and find that superior user interfaces and user experiences eliminate former reservations and barriers. Customers appreciate the enhanced power of the tools available to them, enabling better and more efficient work and a lasting impact on the bottom line.

*****

Vishal Rajpara is the co-founder and Chief Technology Officer of Casepoint. He has always had a vision for transforming disjointed workflows in eDiscovery with more efficient and seamless solutions. Vishal's experience in the legal space spans more than two decades; prior to Casepoint, he has worked in AM LAW 100 firms, such as Crowell & Moring LLP, and legal technology solution consulting companies, such as FTI Consulting.