.png)
Every General Counsel, Legal Operations Manager or Legal Tech Expert will at some point have to face the decision whether to buy some piece of legal technology or create the required tool themselves (“diy”). In this article I’d like to summarize the most relevant arguments for and against the “buy” or “diy” decision. The way I see it, there are always reasons for and against the one or the other alternative. You decide!
By the way: this article is solely my own opinion and represents my personal experience. It does not necessarily reflect the opinion of my employer.
If you’re thinking about implementing a legal tech tool, you’ll obviously have a “problem” you need a solution for. But make sure that you identify the (whole) problem correctly before you jump to conclusions. Because the range of solutions available on the market is diverse. Software providers will promise you things that sound amazing and, in the demos, the solution usually does what it should without any hiccups. So those solutions often seem to be the best choice.
But does your problem (really) require some piece of fancy legal technology? Only because that shiny tool is available on the market and (also) able to solve the problem? Or is it sufficient to do it “quick and dirty” (and faster? and cheaper?) and use some of the already existing technology you’ve got lying around, that is to say “…that you’re paying licensing fees for anyway”? By the way, I’ll be calling that kind of technology “anyway tech”, because it’s there anyway.
An important thing to consider in this context might be if you are capable to solve the problem yourselves. You want to know:
Before you get all excited and jump into work, ask yourselves if you can spare the capacity to work on the implementation of your own legal tech tool. It might be faster and involve fewer external stakeholders. But it will bind resources within your team that you need to be able to spare. As soon as people see that it works and you create a respective demand, the need for resources will grow even more. Believe me! This shouldn’t keep you from trying it, but you could come up against an obstacle. Be prepared for that. You’ve got the manpower? Do it yourselves!
It might seem costly and lengthy if your favorite legal tech supplier presents to you its licensing fees and “one time installment for implementation which can be one within a couple of days easily” (yeah sure). And it can be! But it might also be cheaper and more effective than doing things on your own. Always depending on your given circumstances. If the solution can be operated by one person internally with external support after it has been implemented, that might be more effective than having three people internally implementing, supporting, and maintaining it. However, that calculation might be reversed the more you do yourselves. It can be worth it to support the third or fifth or tenth tool yourselves, whereas it might be cheaper to outsource support for only one or two solutions.
If things go sideways, which they do in a lot of IT-projects, you can always blame it on the software provider or implementation partner. Unless you are doing development and implementation (testing, roll-out, etc.) yourselves of course. Ok that is a very simplified representation of things. But unless you have the confidence that you’ll be able to get things done, you might want to reconsider. All the blame, but also all the praise, will fall on you. If we’re talking about business-critical solutions that becomes even more evident.
Make yourself familiar with what it takes to properly test your solution and be aware that this needs a lot of effort (and resources) on your side if you’re doing things yourselves. You need to prepare test cases and run the tests yourselves. Or you need to involve other stakeholders, which you’ll need to do anyway because you need their input and constant feedback while developing your solution. Are those resources available? Are they willing and able to properly assist you? If you’re assigning an external service provider, you won’t need to think about things like that.
After successful implementation is before further development and re-iteration. You usually won’t have the perfect solution from the beginning. So, you’ll start with a Minimum Viable Product (“MVP”) and develop it further in iterations, according to the feedback from your users. The work is therefore not “done” but becomes an ongoing task. Also consider that your tool will have to be supported and maintained during its whole lifecycle. People will be constantly working on the tools you once developed on your own, solving issues, adding new functions and so on and so forth. But maybe it is even better to use that time and effort internally, instead of spending money for external resources. Which will also need your support, make no mistake about that.
Believe me (from my own experience), nothing is more frustrating than implementing a new legal tech tool and nobody is even aware it exists. I know this has nothing to do with the questions regarding “make or buy”. But is has everything to do with the success of your implementation. Since this article is also about sharing my own experience, I wanted to emphasize it here. No matter if you make or buy, make sure not to neglect the necessary marketing of your solution.
Another thing to blame your external software provider for might be your (internal) customers reaction: “I expected more from that!”, “Why is it only able to do that?” Well, whether you are doing things yourselves or working with an external partner always manage expectations early. If you involve internal stakeholders from the beginning, they’ll be able to influence the features of the solution themselves. That won’t work if you buy something off the shelf. At the end they will get what they wanted and there will be fewer to no false expectations. If you repeat that exercise a couple of times you will end up with a well-coordinated team and things will run smoothly. Try that with your umpteenth service provider for the gazillions’ tool you’re buying instead of making. There might be benefit in doing it yourself.
In both cases you need to be aware that unknown restrictions might occur. With anyway tech those might be licensing restrictions or missing interfaces. But also, if you buy software you might end up in situations you did not expect. Because sometimes the software provider saying: “Sure it will work. No problem. Our solution can be combined with any of the available standard solutions, easy!” actually means “Well, it would usually work. But your case is different! We’ve never experienced that before. Ever!” It’s not a given, that things work out smoothly if you buy external expertise. You might as well do it yourselves.
By outsourcing things to external software providers, you might save your own resources (at least capacity wise) but you and your team might already know how to handle external service providers from various other occasions. Doing things yourselves has the unexpected side effect of confronting yourselves with something new and thus creating a possibility to grow and learn new things. It might also help in gaining new skills which will help you and your team in the future. Finally (and I consider this to also be a “practical tip”) DIY-Legal Tech is fun!
If your tool is being implemented by an external party, you’ll of course need to participate in the process of testing and implementation. And during that will get to know some of the IT people on your side of the business as well. But diving into the matter yourselves will create a different kind of connection between the IT team(s) and you. It will help you to understand each other’s demands and requirements better and enable you to work better together in the future. The same is also true for other relevant stakeholders. Like your legal or data protection colleagues. After your second or third joint project, you’ll each have a better understanding of what the other needs. The likelihood that you will then opt for the diy-approach again increases with every successful implementation of a self-created solution.
Finally, doing legal tech yourselves will create a whole other level of attention and reputation for you and your team. I’ve been told that Legal Departments not seldomly struggle with being regarded as the “Department of ‘No’!”. Well, what about presenting a self-created solution to a problem that shows how you can think outside the box? Create opportunities instead of just pointing out problems?! Getting things done yourselves instead of relying on external service providers?!! And thus become the “Department of ‘Hell yeah!’”. Though that might be hard because typically that place is already taken by the Legal Operations team… Just kidding... Not!
Cost and time saving are not always arguments for diy legal tech. Because it might be as effective to source things out than doing them on your own. Depending on whether you’ve got the necessary technology (“anyway tech”) lying around, the skills and resources to implement, support and maintain the solution. If we’re talking about business-critical solutions, be even more cautious. That’s the “contras”.
When opting for the diy-approach the obvious “pros” are, that it gives you flexibility and will improve your (teams’) skills. You can create an MVP (“Minimum Viable Product”) in a rather short amount of time with limited resources and from then on re-iterate and develop it further according to the feedback from your users.
You might even save time and money. You’ll surely be seen in a different light and strengthens your teams’ position within the organization. It might also help you to attract and retain talent if you can confidently tell them in the job interview that you are developing and implementing your own legal tech.
You dare to try it? To take responsibility, own and manage the tool, involve, and convince stakeholders? Let me tell you, it is not always easy but from my experience it’s definitely worthwhile!
Sign up for a regular dose of news and updates from the legal landscape.
.png)
Get the latest updates about legal and privacy from experts in the field.
.png){kind=small}
.png)
.png){kind=small}