Make vs Buy, or the Not Invented Here Syndrome

I spent the week at Suffolk Law School’s Clinnnovation conference, followed by a great summit where we discussed how to train the next generation of lawyers to code. Imagining a group of excited new coders made me think about the risks and benefits of coding that we might not have time to teach in law school. Lawyers often have a DIY mentality and while the topic has been covered well, I bet not every lawyer will be reading the same articles that businesses and the IT industry read.

As an attorney, developer, and systems administrator at Greater Boston Legal Services, I am often asked which tool to choose for a project.

I have written tools to solve some specific problems. One example is a Powershell platform to help on-board 50-100 new staff and volunteers each year into an array of different platforms, including Legal Server, Active Directory, Office 365, and Big Hand Create. I’ve also created Google Apps Script add-ons to solve specific problems, such as repetitive HotDocs coding. But most of the time, the right choice is an off-the-shelf product, either one that comes ready to go or one that can be customized. This requires my ordinary IT skills.

When does custom development make sense?

I think about a few different factors when deciding to custom code vs adapting an existing tool. The first is to do some basic research to see what is out there. Is there something that gets pretty close to the mark? My first thought when my office changed our case management system to Legal Server was to investigate using web macros.

I looked into a few options and decided that iMacros looked pretty close. However, after playing around with it for a bit, I found it was a little too clunky and had the major drawback of not integrating with our existing Powershell script for onboarding staff. Instead I wrote a browser automation script. I only did this after giving it a fair amount of thought, as I had never used Powershell to automate a browser before.

Another thing to consider is who will be the end user of your tool and how much time you’ll need to spend supporting and maintaining your project for that end user. If you are creating a script that you or a small number of staff will use, custom coding makes more sense than building for a wide audience. The first year or two after I built my user onboarding tool and before it was more mature, I spent at least a week or so a year troubleshooting and adding new features. With more users the demand on my time would have been much higher and would have made buying an off the shelf software tool combined with manual data entry a more sensible choice.

It will tend to be the case if you are solving a widely-encountered problem on a popular platform, there might be an existing solution. This is especially true if the problem you’re solving has an audience of paying customers. For example, sometimes my office buys form libraries, and sometimes we custom build them. For our eviction clients, there’s no commercial firm who can make money selling the form libraries to law firms. For family law and immigration law, there is, because people at all income levels need help with family and immigration law. I value the time I have because I don’t need to maintain libraries for those law areas!

What should you avoid?

It’s easy for a new developer to look at an existing product and decide it’s insufficient to the task. Only once you start working on it do you realize all of the kludges, hacks, and workarounds that made it look so inelegant had a reason for existing. Check the impulse to build a better mousetrap. Sometimes it’s the right idea–after all, most disruptions are improvements on old products, not completely new inventions. But it should be undertaken with the recognition of this risk and weighed against the benefits of the new tool you plan to build. It needs to offer a real advantage to be worthwhile.

Try to be realistic when scoping out the effort to develop, especially something new. Can you afford the time to do the initial development? And don’t forget about the cost in your time to maintain the system. Rarely can you release a software product into the wild and not have to update it.

Be realistic about your expertise. For example, if your project will have public use, can you be confident in your ability to code it securely? Every week there are breaches of major corporations. Your software might not draw the same attention, but if you store private information, you might even be opening up a legal risk. This is solvable (and many projects won’t store private data) but should be weighed. It’s at least worth considering data segregation and using a VPS rather than hosting it on your company’s servers inside your firewall.

Consider the cost of the alternatives. Even if your great new tool will save time or money compared to a commercial solution, if the amount saved is relatively small or it will take too much time to develop, it won’t be worth it. We buy a subscription to pre-packaged third-party updates instead of saving a few hundred dollars by packaging them ourselves. This easily pays for itself.

The same process should be applied to evaluating building from scratch, compared to adapting an existing web framework. It would be malpractice for most web developers to build a website from scratch when WordPress or Drupal would meet the customer’s needs (of course recognizing that sometimes they won’t be the right fit!). With so many platforms for automating the law, careful attention should be given to whether one of the choices out there, like Docassemble, HotDocs, QnA, or A2J author will work for you.

Conclusion

Software developing opens up a world of exciting new possibilities for time-saving and business-expanding ideas. But new lawyers should enter that world aware that not every custom software project is a great idea.