When should a law firm develop its own software?

by Timothy B. Corcoran on November 7, 2016

Facebook Twitter Email Linkedin Delicious Reddit Stumbleupon


Never. Law firms should never develop their own software. <end post>

Okay, fine, perhaps some explanation is in order. While the above conclusion may seem obvious to me and to many others, whenever I make this assertion on Twitter or from a podium, more than a few people will question my sanity or try to uncover my hidden bias. My bias isn’t hidden at all. My view is developed from a lifetime of selling software, managing teams developing software, managing teams configuring and installing software, and managing teams buying and implementing software. Of course, the world isn’t so black and white that one answer applies to every situation. But, by and large, law firms should practice law, not write software code. Here are 6 reasons why.

ivoYou need to stay focused. Smart business leaders outsource when (a) the all-in cost of buying is lower than the all-in cost of building; or (b) when in-sourcing will divert needed resources from strategic imperatives to non-core, non-strategic functions. Just as corporations hire law firms – because investing in a huge law department to handle all legal needs would be more costly and disruptive than hiring on-call experts — law firms should outsource their non-core activities. So a law firm CIO is better off purchasing software that can be configured to the users’ needs or, at worst, hiring a software vendor to write code specific to the users’ needs.

Check your math. If your calculation suggests you should build vs. buy, you’re likely doing the math wrong. The all-in cost, or total cost of ownership, isn’t simply about software seat licenses, initial configuration, and ongoing maintenance fees compared to the sunk cost of Steve in the IT department who can write code. The all-in cost requires a broader look at the learning curve for common features/functions, R&D time for new features/functions, quality assurance and load testing, fixing bugs and releasing periodic patches, gathering ongoing user requirements, maintaining a product roadmap of features/functions having the widest impact to the user community, training users, providing front-end support such as password resets, providing second-level support for major bugs or conflicts, management reporting, and, oh yeah, coding. By the way, nowhere in your calculus or rationale should we find: “We have a software developer on staff and we need projects to keep him or her busy.” Software purchases can be expensive. But it’s short-sighted to view a vertical or enterprise application as solely a cost; it can be an investment too, with significant returns. Many organizations offset costs by demonstrable improvements in costly workflow, reallocating headcount doing things the old way, eliminating fees for outdated software, and even generating revenue.

You’re not a special snowflake. Your users’ requirements are not as unique as you think they are. Every single law firm partner believes the firm’s work environment, internal processes, client interactions, and lawyers are unique. They’re really not. What’s worse, too often the most vocal advocates of a unique culture have literally never worked in another environment, let alone another law firm, so their perspective is meaningless — despite what the org chart may reflect. A software provider with 10, 75, or 175 clients facing substantially the same business challenge may have deployed numerous iterations or configurations to address unique user requirements, but the core code is substantially the same and flexible enough to adapt to hundreds of other iterations. If you research existing solutions and don’t find the feature or function you seek, it doesn’t mean it’s not out there. Sometimes a feature isn’t in the base code but is commonly configured in the customer’s deployment. Many times a feature or function is on a software vendor’s radar but it won’t be added to the next version until enough clients express a willingness to buy. Talk to trusted providers and you may find the path to meeting your requirements doesn’t require starting from scratch.

Your requirements are incomplete. I can’t count how many law firms I’ve encountered with code written to meet one specific partner’s or one specific client’s needs, as expressed through a vague description of desired outcomes, and ignoring all other viewpoints. Gathering business requirements and then translating them into technical specifications and then into code is a discipline, and even Agile and lean environments don’t rely on coding to a single user’s needs. Inevitably, if what you’ve coded is a good idea from which other internal users or clients would derive benefits, and it often is, the code you wrote for one specific instance — especially if it contains hard-wired references to a specific client — is very challenging to build upon. To scale it, you’ll need to rewrite. In software development, it’s better to think ahead and write modularly rather than frequently pay for one-time throwaway code. Also, capture input from all stakeholders. Countless times a partner establishes the requirements but the client, or the legal secretary, or the billing clerk, is a key influencer or user who had no voice in the development. It’s no surprise why adoption rates are so low. Quality software developers capture input and seek sign-offs from all stakeholders before writing code.

Your discipline is suspect. I’m sure Steve in IT is a good code writer, even though his day job is network administrator, or help desk tech. Even if he’s hired specifically as a coder, one resource isn’t capable of gathering requirements, translating business requirements into tech specs, writing code, testing code, documenting code, conducting user testing, training users, and fixing bugs upon release. Having Steve attend a meeting with the partner and then begin to code from his meeting notes isn’t enough. Few law firms invest in quality assurance and proper load testing, and even fewer invest in virtual environments to replicate their user community experience, including testing for conflicts with other enterprise applications. I’ve also run into law firms with the source code housed on one machine with no off-site backup protocol, and others where only one person has access to the source code. Just as you counsel your clients to hire the right law firm for the job, look for a disciplined and experienced software developer that isn’t going to make rookie mistakes.

Reliance on a single point of failure is risky. We know that Steve doesn’t have time to write up a summary of the business requirements let alone document his code. So what happens when Steve leaves and you need to fix or add something? Yes, of course you can find other coders pretty quickly, but their first task is to trace the existing code to figure out how things work. This takes time. And what if, as we inexplicably continue to see today, the current code base is ancient and the availability of coders fluent in that outdated language is limited? What if Steve leaves in a huff and deletes the source code, or changes the password? I recently worked with a law firm that had developed a specialized application some years prior and dozens of clients had embedded this app into their workflow — a perfect demonstration of the value of switching costs in a business relationship. Trouble is, the partners didn’t fully appreciate the role of their two software developers and laid them off during a cost-cutting exercise. “We have other people in IT who can run with this,” they said, ignoring the importance of subject matter expertise and specialization in a way that they’d never apply to the firm’s lawyers. Predictably, the code faltered, the clients grew dissatisfied, and the clients untangled their workflows from a suspect system. (Side note: partner profits increased a healthy amount that year even as firm revenues grew modestly, but <surprise!> profits declined the following year.) Invest in the redundancies and peace of mind that come with purchasing software from trusted vendors.

The selection of a software package or provider is complex, as well it should be for enterprise or mission critical needs. Some vendors are better than others, and the size of the company or global breadth of the brand are often false indicators of competence. It’s necessary to address to your satisfaction common questions and objections such as depth of domain expertise, development process, architecture and infrastructure, configurability of the software, compatibility with existing systems, responsiveness and service posture, and, not unimportantly, how likable is the team you’re going to be doing business with for multiple years. And yes, the price tag on the software matters, but only insofar as it’s one factor in your total cost of ownership calculation. (Side note: If you’re a software vendor CEO and your team isn’t incorporating TCO into its sales motion, call me. Your poorly-trained salespeople are missing opportunities to solve customer needs and close deals.) I know you’re in a hurry. But if you rush to do a poor job instead of taking time to do it well, I don’t think “fail fast” means what you think it means.

Keep in mind, the question isn’t whether you can write good software code. Let’s assume you can. It’s safe to assume any competent coder can produce a good software application… once. But if your business case requires this code to be supported, upgraded, reconfigured, or replicated down the road, it’s healthier to start with the premise that others are better suited to provide these services in a long-term business partnership. Avoid falling into the trap of assuming that “We can do this” or “It makes my job or my team’s jobs more secure” is a good rationale. The best job security comes from finding the right people with the right skills and giving them the resources they need to be exceptional.


Timothy B. Corcoran served as a senior executive with several global companies and has managed numerous software rollouts. He was the 2014 President of the Legal Marketing Association and is an elected Fellow of the College of Law Practice Management. He delivers keynote presentations, conducts workshops, and advises leaders of law firms, in-house legal departments and legal service providers on how to profit in a time of great change. For more information, contact him at +1.609.557.7311 or at tim@corcoranconsultinggroup.com.

Print Friendly

{ 2 comments… read them below or add one }

Timothy B. Corcoran November 8, 2016 at 7:49 pm

The birth of e-Discovery is a great example of an idea incubating in a law firm but that got legs once the law firm partnered (or founded/funded) a company dedicated to software development and sales. I’ve witnessed numerous ideas like this over many years, from plaintiff firms and defense firms, from small and large firms, and many of the ideas are good ones. But so many fall into the ash heap of history because the firm either tries to do too much itself (“Steve in IT coded this for Client A. How hard can it be to expand this to Clients B-Z?”) or they make rookie mistakes about market appetite (“Let’s form a new company and sell this brilliant idea to our competitors!”) or they think it’s a billion dollar idea so they won’t trust any business partner, or any of a dozen other mistakes. I don’t think we disagree at all. The example you cite reflects a law firm relying on a technology company to take its idea to market. There are a thousand good ideas out there, some being advanced every day by law firms pushing the boundaries of their enterprise systems; others being killed by enterprise developers, particularly incumbent players, who can’t see over the horizon. I’m with you that the greatest innovations will likely come from the small technology players, many of them new disruptive entrants. We need more of this!

Jason Moyse November 8, 2016 at 7:11 pm

Never you say? I’ll take that bet.

Preston Gates & Ellis commercialized its own technology, in part by acquiring $4 million in venture capital and then forming the separate company Attenex which was one of the early day e-discovery vendors. And like many legaltech aspirants of today, they had a nifty exit when they sold the company for $88 million in 2008 with a 5x return for the investors. I wrote about this –> https://techvibes.com/2014/10/22/future-of-legaltech-lessons-past-2014-10-22

Perhaps the middle ground between subjecting firms to historically abysmal legal technology players and having them leap out on their own is to co-create in partnership with vendors that are truly interested in seeing their clients succeed. THAT is design thinking.

Every other industry is having Digital Davids dance with Enterprise Goliaths and law should be no different. At minimum–firms should work with vendors — even if they are startups! ESPECIALLY if they are startups. The days of a single purpose products are toast and bricolage will prevail, if not outright builds. But certainly relying on traditional vendors is a mugs game.

Leave a Comment

Previous post:

Next post: