A conversation about AI tools for legal and public tenders with Johannes Steinbrenner, Lead Product Engineer at Libra, Henrik Volkmann, Director Revenue at Libra, and Leonard Wossnig, CTO, Forgent.

Interviewer: Felicitas von Rauch, Founding Growth Lead at Forgent

Felicitas: Henrik, how often do you hear the statement "We can build that ourselves" in customer conversations?

Henrik: We actually hear that rather infrequently. It depends heavily on the size of the law firm or legal department. For small and mid-sized law firms as well as corporate legal departments, the question often doesn't even arise. Over 60 percent of all lawyers in Germany work in firms with no more than five people. Firms with fewer than 20 lawyers typically lack the capacity to assign someone exclusively to technology. In those cases, it's the partners themselves who deal with legal tech if at all. Starting at around 20 lawyers, firms begin to think systematically about their technical infrastructure. Their first instinct is to look at the market and existing solutions, because even here the resources for in-house development are lacking. Only when the available offerings don't meet their specific requirements do they consider building their own solution.

Leo: At Forgent, things look a bit different because we work extensively with enterprise clients. Large companies are more inclined to develop internal solutions. A consulting firm with ten thousand employees, for example, has entirely different internal capabilities. The relative costs to build inhouse are significantly lower than for a small company. However, in every benchmark we've conducted, internal solutions have consistently underperformed. In most cases, they turned out to be hastily assembled ChatGPT wrapper, despite budgets of five million euros and more.

Felicitas: What are the most common reasons why companies still try to build their own solutions?

Henrik: Historically, the main reason was that the products law firms truly needed simply didn't exist. Before the AI era, legal tech was a largely overlooked field. There were a few small tools such as a Word add-in here, timekeeping software there. At the same time, every firm was convinced that its requirements were so unique that technology had to be fully custom-built. It was only with LLMs that the possibility emerged to deploy technology at scale. Beyond that, control and customizability naturally play a role as well: knowing exactly what happens with the data, whether everything is secure, and whether the system can be tailored precisely to one's own use cases.

Felicitas: What has changed over the past two years?

Henrik: The market has fundamentally transformed. Thanks to AI, there is now software that is broadly capable, covers numerous use cases, and is also interoperable, i.e. offering integrations with a wide range of other tools. Firms that continue to rely on in-house development are increasingly finding that they're being overtaken by technological progress and can't keep pace with the speed of innovation.

Johannes: What has changed is the market maturity. Two or three years ago, the concept of a Legal Workspace like Libra didn't even exist. Back then, it was entirely conceivable to build a chatbot yourself. But as products evolve, expectations rise accordingly. At a certain point, the complexity becomes so great that in-house development is no longer realistic. It's comparable to how nobody today would think of rebuilding Google Cloud, even though 20 years ago companies routinely operated their own cloud servers.

Felicitas: What technical efforts are most commonly underestimated when building in-house?

Johannes: There are aspects of a product that simply cannot be replicated in-house at scale. A good example is integrations: our product can be seamlessly embedded into other solutions, which significantly increases its value. Of course, you can try to rebuild such a feature. But then you're permanently faced with the challenge of maintaining and expanding integrations. That's an ongoing effort, and you'll always be playing catch-up with a specialized solution that pursues exactly this as its core objective.

Leo: We've invested considerable time in demonstrating the technical complexities involved in building a domain-specific AI tool for public tenders. The complexity ranges from context engineering to the hundreds of requirements that need to be extracted from a tender, to a planning mode in which individual chapters are generated consistently. And the risk is high. If even a single requirement is missing from a tender response, the bidder is disqualified. Many companies underestimate this complexity. Modern coding assistants make it possible to set up a solution very quickly that works well for a handful of inputs. But reliably consistent quality is where it falls short.

Felicitas: Henrik, let's talk about adoption. What role does it play in the make or buy discussion?

Henrik: Adoption is arguably the most important argument of all. Internally developed tools may be technically competitive. A ChatGPT wrapper in a secure Azure environment, for instance. But what matters is not that a solution works in principle, but that it's actually used. UX/UI plays the decisive role. Specialized providers like Libra can ensure sustained usage far more effectively because they develop a thoughtful user experience. This leads users to enjoy using the tool and to use it regularly. Internal tech teams, by contrast, face less pressure because no internal alternative exists. They don't have to compete in the market and can essentially mandate that employees in the organization use the tool. Historical comparisons illustrate the point: it was only with the graphical user interface that computers achieved broad adoption. The mobile internet only became mainstream with the touchscreen. And with AI software, it's exactly the same. There will always be lawyers who want to configure everything themselves. In a firm of 100 people there might be one technically adept employee who builds a solution that works. But nobody else uses it. Or each one uses it differently. The critical question is: am I building this just for myself, or for 90 other users who may be far less tech-savvy?

Johannes: There's an additional factor that's nearly impossible to replicate when building in-house: the innovation culture of a startup. In a startup, everyone is intrinsically motivated to continuously develop and improve the product. This dynamic is frequently absent when an external service provider implements a project or a small internal team is tasked with development.

Felicitas: How does Libra specifically manage to increase adoption at law firms?

Henrik: We rely on what we call Legal Engineers. These are lawyers who possess deep knowledge of how AI can be applied to solve legal questions. They bridge the gap between what's technically possible and what lawyers need in their daily work. This requires both technical and legal expertise. If you hand a lawyer an AI tool and tell them to just try it out, they'll enter some random legal question. The answer might not be convincing, leading the lawyer to dismiss AI as useless. But if you show them how to configure a specialized assistant for their specific problem, e.g., extracting legal arguments from a brief and presenting them in a structured format, that's when real "aha moments" happen. This kind of guidance is something we as a specialized provider can deliver far more effectively than an internal team.

Felicitas: For clients who initially built their own solution and then switched. What was the decisive moment?

Henrik: Typically, these clients discovered through direct comparison that Libra delivered better results, both in terms of output quality and usability. And above all: users preferred it and used it more frequently. That's ultimately the deciding factor. There's little value in having developed a technically sophisticated tool in-house if nobody ends up using it.

Leo: We offer a direct comparison between the client's in-house solution and Forgent. In the best case, the company discovers that their tool performs well. In most cases, however, they find that Forgent performs better. With one major client, we processed the same tender using both the internal tool and Forgent. A jury evaluated the results in a blind test, without knowing which solution had produced which proposal. Forgent won. This is a particularly compelling argument because the internal team members were seasoned tender experts. And still couldn't achieve a better result.

Felicitas: Johannes, what question should I have asked that you find particularly relevant in the buy vs. build discussion?

Johannes: I think the often underestimated added value that comes with purchasing a specialized solution deserves special mention: the external impulse. You can develop the most technically sophisticated tool imaginable. But if users don't understand how to use it productively, it misses its purpose. The effort involved in systematically onboarding customers and sparking curiosity about new use cases represents significant value. This doesn't necessarily have to take the form of elaborate pilot phases with multiple engineers. Well-designed onboarding materials can already make a substantial difference. Beyond that, the data aspect is critically important: we have access to legal databases and publisher content that can neither be replicated nor easily procured. This is a structural advantage over in-house development that is extremely difficult to overcome.

Felicitas: Thank you for the conversation!

Libra is a legal AI tool built to support daily legal work and used by over 700 leading legal teams.

Forgent AI helps companies to win public tenders with their end-to-end AI platform.