Having been an EED software user for some years, I read Law Technology News’ article on E-discovery tools with some interest. While I agree with the author’s assessment about core code in tools, I don’t believe that the underlying code should be the prime differentiator for making purchase decisions.  In much the same way that Apple has carved out a piece of the computing market by building software which allows complex tasks to be handled easily, the measures for software purchase can be explained by combining usability with insight into the processing function. In other words, pay attention to the front end.
It would be easy to believe that processing speed is the differentiator.  I know people that focus on megapixels when they buy digital camera equipment, but after the images are recorded, does the camera actually render a decent image?  I believe the same can be true for processing software.  It may run quickly, but does it provide reporting and other insight that help present the “best picture” of processing to the client?
So, while tools may rely on similar software to process data, nothing will substitute for a front end that allows the operator to understand what’s really going on with the data.  Are there password protected files?  Are there zip files that can’t be opened?  Are there other forms of corrupted files?  The ability to account for every single file received with a Chain of Custody form is of prime importance if a vendor wants to be seen as a responsible and diligent provider.

If you were to build a data processing tool, what new components would you include?