Should you buy a document automation solution or build it from scratch?
When it comes to automating your document creation process, this is one of the most critical decisions you will need to take. It’s also hard to nail. In this article, we’ll explore the pros and cons of building vs buying, learning from some real use cases.
Here's a preview of what this post will include:
Weighing pros and cons of build vs buy in document automation
Cost
The immediate investment needed for building a document automation solution is obviously higher than buying an existing product. But how much higher? Document automation technology may not seem very a complicated enterprise on the surface.
There are even open frameworks to leverage and put together a functioning MVP in days. But is this always enough? Let’s break down the topic of “cost” more granularly.
Design Cost
When building a document automation platform, it’s a good idea to get UX designers involved early on; however, good UX is often considered an afterthought in many “in-house” solutions. The final product often tends to resemble a polished version of the early MVP, with very little attention toward making the product user-friendly and intuitive.
It's pivotal to focus on good design, because:
- Good UX speeds up the time needed to automate templates and create documents;
- A platform with good UX is easier to learn and use;
- Solutions that are easy to use and learn will be adopted. If something is difficult to use, users will leave it aside. Often, it’s not enough for technology to be imposed top-down on users to get them to use it.
For legal teams to reap the benefits of software, they have to use it. To ensure everyone uses the software, firms and developers must focus on the user experience.
It’s common for people to resist change and fall back on their tried-and-true solutions—even if that means taking notes on a yellow legal pad.
Tim Scott, Head of Product Strategy & Design, Frogslayer
Development Cost
As we saw, developing a basic document automation solution may not, per se, look a complicated enterprise; it could even take just days to put together a functioning document automation MVP, perhaps leveraging open-source software like Docassemble.
Once you look at what’s available on the market, the discourse gets a bit more complex. Document automation platforms are not just about inserting variables and conditions; many have grown to include numerous features that add complexity to the system. For instance, some platforms now allow you to:
- Produce multiple documents from a single questionnaire.
- Mass-generate agreements by simply uploading an Excel file.
- Add clauses from an existing clause library.
Moreover, several document automation platforms have now morphed into full-fledged CLMs, offering built-in negotiation and signature capabilities.
Clearly, the functionalities you choose to include depend on your specific needs and use cases. However, the value of many features often becomes evident only after users begin using the platform and realise, "We might need this functionality!"
Even if you are leaning toward the "build" route, checking what existing off-the-shelf platforms offer in terms of functionalities and capabilities can be extremely useful for understanding what you need to incorporate.
Maintenance cost
Finally, you need to take into account the cost and time needed to maintain the solution. Fixing bugs, applying patches and security updates, maintaining an open channel of communication with users to report issues, provide feedback, and request additional features would require a dedicated person in the IT team.
MLOps
If the solution incorporates AI, you also need to consider the cost of hiring a team of data scientists and ML experts to develop, test, and train a reliable model. Although open-source solutions are available, AI projects are time and resource-intensive, and ML expertise is in high demand.
All in all, everything depends on the features required, but from a purely cost perspective it’s safe to say that building a document automation solution in-house would require a larger initial investment than buying it. The question is whether this investment could be recouped after a few years.
Time
Another factor to consider is time. This is a no-brainer in the build vs. buy legal tech dilemma: the time spent designing and developing a document automation solution from scratch is greater than the time spent buying it, right?
On the other hand, don’t underestimate the time it takes to choose a platform from the market.
Both "build from scratch" and "buy off-the-shelf" processes have an initial phase of "exploration."
Understanding Users' Needs
This is a phase that is often overlooked in both buying and building scenarios. It is pivotal to understand users' pain points and what exactly they need the platform to do.
Numerous lawyers were dissatisfied with the products available at their firm, as often they were not relevant to their day-to-day practice.
As one associate mentioned, a crucial problem is “that the people who make the product often haven’t talked to the people who actually do the work.
A respondent to a research funded by InnovateUK
To understand users’ needs:
- Interview them early on to understand their needs, and continue doing so when you are scoping the solution;
- Create focus groups with all the parties involved in the document creation and automation process – this could include senior and junior lawyers, as well as more technical figures in charge of implementing the automation, such as knowledge managers, document automation specialists, or IT professionals;
- Map and understand their processes and use cases.
Researching Products on the Market
If you choose to buy, keep in mind that researching the market also involves a significant amount of time. Consider that you will need to go through at least these two steps:
- Creating an RFI – This is probably the most time-consuming process. To create an RFI, you need to understand not only the users' needs but also the features that platforms offer; prioritise them into must-have and nice-to-have categories.
- Testing Short-listed Platforms – You may want to enroll in a free trial or pilot of the solutions that you have shortlisted. Nothing is better than testing and tinkering with technology firsthand to see if it fits your use cases and to evaluate how easy it is to use.
All in all, although time investment is generally less significant than building from scratch, buying can still be a lengthy process.
Data security
Document automation solutions deal with contracts, which are, by definition, sensitive objects. For many, building a document automation solution in-house provides more control over the data stored in the solution than relying on a third-party off-the-shelf platform.
Myth: Does building give you more control over data/security issues?
Certainly, when you build a solution, you have one important element on your side: control. You can choose where to host your data, what security measures to implement, and you don’t have to trust third parties with your data.
Having control, however, comes with responsibility. You still need to ensure that a number of security measures and policies are implemented. This can be onerous and time-consuming, especially for law firms that do not have a large IT department. Ask yourself, can you realistically take care of security better than a vendor?
Some aspects to consider:
- Creating and Updating Policies and Processes – This would include producing or updating policies covering several areas: access control, incident management, business continuity, secure software development, vulnerability management, and physical security. You would need a team able to design, write, and update these policies.
- Implementing Security Measures – Security measures need to be implemented. Fixes and security patches need to be applied, penetration tests carried out, etc. This also requires a dedicated team.
Ensuring Security standards when buying Document Automation
On the other hand, if you decided to take the “buy” route, you also need to make sure that your vendor has high data security and privacy standards.
A few aspects you may want to cover:
- During your RFI, ask detailed questions about the security measures that the vendor has implemented.
- Choose a vendor that complies with GDPR or a similar regulation. This sets stringent data protection standards, in addition to the ones the vendor may voluntarily comply with.
- Make sure that your vendor has obtained certifications like ISO 27001 or SOC 2, which ensure that further, more stringent security standards are respected.
Risk of lock in
When discussing lock-in risk, many assume that building in-house appears to be the least risky option.
Certainly, it is true that there is a risk that the solution you have chosen may exit the market, leaving you with software that no one maintains, or worse, software you can no longer use.
But have you considered the opposite scenario? What if you grow weary of your current proprietary platform because it is too cumbersome to maintain and wish to switch to a licensed software? You might find yourself trapped in a coded platform whose intricacies only your developers understand.
What happens when technology and security move forward and you are heavily dependent on custom technology, potentially built in a software language that few can understand?
The banking world knows this far too well, maintaining 20+ year old systems written in outdated software languages and paying through the nose for developers who are expert in 'last gen' technology.
Legal Technology Solutions: Buy vs Build. KPMG Report
The risk of lock-in is very real and can be equally painful for in-house coded platforms as well as licensed ones.
There are a couple of antidotes:
Due Diligence – During the RFI, try to determine whether your vendor is reliable and stable. Look at their financials, how long they have been operating, and the size of the company.
Data Portability – You can mitigate the risk of lock-in by ensuring you can migrate your documents with minimal hassle. Here are a couple of ways to ensure data portability for your solutions:
- Exporting – Ensure your data can be easily exported in standard formats (for instance .docx, .xlsx, .cmp) and imported into other systems. At Avvoka, for instance, we enable the export of metadata via integrations and APIs in .xlsx format. This ensures you can switch to another system of your choice at any time without the need to re-automate your contracts.
- Seamless Importing of Other Vendors’ Markup – Conversely, if your current system does not allow data export but you still want to switch, you can ensure the receiving system easily accommodates this. For instance, Avvoka supports seamless switching from platforms like Contract Express or HotDocs, eliminating the need to redo the automation process.
The value of optionality
Another element to consider is that of optionality, aka "putting all your eggs in one basket."
On the long terms, building from scratch could potentially lead to a significant payoff—recouping the initial investment over time. It could also have the benefits of a tailored solution with complete control. But it could also come with significant downside risks.
In a strategy that entails optionality, you don’t have to be right that often. Just the mere fact that you have more to gain than to lose in each bet is sufficient.
Nassim Nicholas Taleb
No time to recoup the costs - There may not be enough time to offset the substantial costs of development, as was the case for Clearspire and Atrium, two innovative law firms that decided to build their legal tech stack from scratch.
Technological advancements - Additionally, the solution may quickly become technically obsolete. For instance, GenAI is now transforming the traditional way we develop software, potentially leading to unexpected advancements or changes that could make the technology outdated.
Market changes - Moreover, the market could shift over the next 8 to 10 years, with law firms and legal departments increasingly outsourcing contract drafting to ALSPs.
In other words, legal technology and the legal market are evolving rapidly, offering numerous potential futures—though predicting these outcomes is challenging.
Outsourcing the risk to a document automation company might provide a decision with lower risk compared to pursuing a costly development project.
Case studyClearspire and Atrium: when in-house development went wrongRemember Clearspire and Atrium? The two innovative law firms shared similar business model and a similar fate. Clearspire was created in 2008 to replace the traditional law firm model. “Big law at half the price” was their tagline. They invested heavily in process optimisation and technology to keep costs down, and cut off “expensive real estate, corporate art collections, and bloated staff” (Marc Cohen). The core of their technological efforts was Coral, a giant system developed in-house for taking care of document management, HR workflow, project management and much more. Atrium, born in 2017, was a hybrid law firm and legal tech company. It pocketed a 75$ million investment, and targeted the legal needs of startups, offering a monthly subscription service. Like Clearspire, Atrium also developed their tech system in-house and they weren’t shy about trumpeting it as “an unmatched technology platform that redefines legal services”. “My view then was that we were witnessing shades of what happened to Clearspire. A similar startup that failed I reckon due to trying to reinvent the Legal Tech wheel and investing too much money in doing so. Atrium had an even bigger pot of money to burn, yet did the very same thing.” Brian Inkster, founder of law firm Inksters Both projects failed – Clearspire in 2014 and Atrium in 2020. The reasons for their demise have been articulated by many commentators. Lack of product-market fit, unclear brand and weird pricing model are recurring in many post-mortem analyses. Another main element is also regularly cited: the whopping cost of developing and maintaining their software stack. A cost that neither Clearspire nor Atrium were able to recoup in the short term. “Anyone else got the sneaking feeling that these folk have built HighQ from scratch?” Alex Smith, Product Director at iManage |
Customisation
Developing a solution in-house has a significant advantage: creating your own document automation platform allows for precise customisation to meet specific needs, especially when workflows and use cases are unique. Thorough research into users’ pain points and requirements ensures the in-house development results in a perfectly tailored solution.
However, other aspects should also be considered.
Some vendors are open to customising their solutions for you
Some vendors may offer customisation options to secure a deal. You can take a proactive approach by inquiring about the customisations you need, their associated costs, and the timeframe for implementation.
Furthermore, some vendors maintain open channels with their customers through communities and user groups. These platforms are designed to gather feedback and accommodate new feature requests.
Using APIs to build customised integrations
Leveraging APIs could strike the right balance between cost-effectiveness, quick time-to-value, and customisation.
Some document automation platforms offer APIs that empower users to extend their functionality. With APIs, you can tailor existing document automation platforms to suit specific use cases. This can be achieved by developing integrations from scratch or by integrating the platform with other existing systems, such as document management tools.
APIs represent a paradigm shift from the traditional Software as a Service (SaaS) model to a new Platform as a Service (PaaS) model. They enable extensive customisation and seamless integration of "off-the-shelf" software, thereby mitigating risks.
There's always been the question of build versus buy, but now there's the advent of a third choice. I can leverage an existing platform and build on top of that, which is a hybrid example that might accelerate the traditional build process.
Craig Dean, CTO at Orrick
Risk of customising an off-the-shelf solution
When customising an off-the-shelf solution, be mindful not to compromise too much!
It's crucial to understand how well the customisation aligns with your specific use case, and to what extent customising an existing product carries the risk of creating a patched-together solution that jeopardises functionality.
Also consider that integrating commercial software with your existing systems can pose technical challenges, especially if the software was not initially designed to interface seamlessly with your specific tools and platforms.
No-code
"No-code solutions are a wildcard in the build vs buy dilemma," as someone once said, and we agree.
These platforms enable the development of solutions or integrations from scratch using intuitive building blocks, often at a fraction of the time and cost of traditional development methods.
For example, Betty Blocks provides no-code and low-code "building blocks" tailored for the legal market. Large law firms and legal teams use their platform to create document review, GDPR assessment, and document automation solutions.
Another example is Percipient, an alternative legal service provider. They utilise Zapier to develop a straightforward document generation tool that swiftly compiles NDAs from customer-submitted data, at minimal expense.
The benefits of no-code solutions include reduced development costs, faster time to value, and the ability to customise solutions to specific use cases with ease.
While they may not yet offer the flexibility of fully coded solutions, they are viable options for less complex use cases or as tools to integrate with existing solutions, leveraging existing platforms’ APIs.
GenAI
Introducing GenAI into the mix adds another dimension to the build vs buy dilemma in legal tech, offering food for thought in the debate.
Large language models (LLMs) represent a powerful new tool that appears to open up "an endless succession of magnificent possibilities" for lawyers, prompting several law firms to explore their potential. For instance, see how the law firm Gunderson Dettmer is leveraging GenAI with their AI assistant ChatGD.
What makes GenAI particularly interesting is not only its ability to approximate human thought processes but also its accessibility and affordability. Rather than training or fine-tuning the model from scratch, users can harness GenAI APIs through clever prompting and retrieval augmented generation.
In practical terms, this means feeding the LLM a set of questions and answers to learn from, along with access to a contextual database (e.g., legal databases) for additional information.
Case studyChatGD In August 2023, Gunderson Dettmer launched ChatGD, an internal generative AI chat application based on OpenAI. Technology – ChatGD works with retrieval-Augmented Generation (RAG). There is no fine-tuning or model training involved but a mix of clever prompting and access to a database of specific information. Lawyers can upload documents or collections of documents and then query the LLM and receive responses based on the context provided by the documents. Use cases - So far, the firm has used ChatGD for a series of legal and non-legal tasks. Legal tasks: drafting summarising legal documents and brainstorming legal language. Non-legal tasks: drafting RFP responses, data structuring, coding. Costs - In a post, Joe Green, Chief Innovation Officer, states that the projected annual cost for providing ChatGD to the entire firm would be less than $10,000. They attribute the cost-effectiveness of ChatGD to two decisions: (1) self-hosting the open-source model. GD has installed OpenAI on an Azure Cloud, instead of relying on OpenAI servers; this is more cost-effective, but also guarantees more control over the data; (2) leveraging GPT 3.5 Turbo for both pure chat and RAG functionalities instead of using the most expensive models available. “We framed the rollout of ChatGD as a collaborative experiment designed to help everyone move up the learning curve and to crowdsource the most promising use cases and methods for getting the best results out of GenAI-powered tools” Joe Green, CIO, Gunderson Dettmer |
So, building or buying?
The answer is... it depends!
From a cost perspective, buying is more convenient than building in the short term. However, in the long term, the situation is less clear (assuming your build is successful and maintainable...).
Customization is definitely a winning point for building, especially if users need very specific workflows.
However, buying off the shelf is still very attractive, not least due to a few more recent developments:
- No-code solutions: These introduce another intriguing dimension, enabling rapid, cost-effective development of integrations or entire solutions, allowing users to keep costs low and accelerate development.
- APIs: These present a powerful yet underutilised tool, allowing users to extend and customise existing off-the-shelf solutions, integrate with other systems, and tailor solutions to specific needs.
- Integrating GenAI: This offers access to a realm of powerful possibilities, enabling experimentation with different use cases and enhancing the capabilities of document automation platforms.
