July 29, 2024
A guide to building vs. buying AI
It’s now easier than ever for life sciences firms - even those with relatively little AI expertise - to build AI tools. In fact, that’s what makes this particular wave of AI so much more powerful than those before it.
Approaching AI
It’s now easier than ever for life sciences firms - even those with relatively little AI expertise - to build AI tools. In fact, that’s what makes this particular wave of AI so much more powerful than those before it.
Easy access to developer-friendly APIs, intuitive use cases, and the cloud have all made it incredibly easy to engineer basic AI tools in a matter of minutes or hours.
The ease of access to AI technology today is a double-edged sword for companies. On one hand, it's incredibly beneficial because even firms with minimal AI expertise can now develop AI tools with relative ease. However, this accessibility also complicates decision-making about how to best leverage AI. Companies are now faced with the (perhaps fortunate) decisions of how to build AI. So far, we’ve encountered three main approaches: build in-house, buy from a vendor, or outsource the building and in-house the continued maintenance.
The rest of this blog post lays out the pros and cons of each of those decisions. Perhaps surprisingly, there are really only three or four dimensions that this decision is made on, and they can be pros or cons, depending on the situation.
The Main Considerations
Building in-house is perhaps the most attractive option for the larger end of life sciences companies. This is because there are a few potential benefits to be realized when building in-house:
Data and privacy concerns. Building in-house often offers increased privacy and data security guarantees, as it allows companies to keep sensitive information within their own controlled environment. By managing the development process internally, organizations can implement stringent security measures tailored to their specific needs and have much greater transparency over how data is handled. Especially given the nature of the data, this is often a key concern.
Cost. Building in-house can sometimes be the cheapest option because commercial software, especially in the life sciences space, often comes with hefty licensing fees and ongoing subscription costs. By developing AI solutions internally, companies can avoid these recurring expenses. Additionally, in-house development allows for incremental investments in technology and expertise, which can be more manageable than the upfront costs associated with purchasing enterprise-level software from vendors. Especially for large organizations where large technology investments can be amortized over a large user base, this can make sense.
Integrations. Many life sciences organizations have highly custom integrations or workflows internally. If the complexity of these workflows is high-enough and custom enough, many companies may decide to build AI in-house due to concerns that vendor solutions that are designed to scale to as many different customers as possible may not be adequately equipped to integrate into their workflows.
Quality. This might be the surprising one, but this is critical, and one that we’ve seen over and over. Because many organizations that have the ability to build this in-house also have highly sophisticated workflows, it’s better for many to develop AI tools specifically for their workflows. This is because, similar to the point on integrations, many companies have particular styles and preferences for the documents or workflows their AI products are designed for.
On the flip side, the main concerns organizations have when it comes to building in-house (and the reason that many will choose to work with a vendor) are:
Quality. This occurs on two fronts: 1) oftentimes, third-party vendors, if developing AI technologies is indeed their core capability, will be structured to recruit top-tier AI and subject matter expert talent, allowing them to build higher-quality products, and 2) because developing AI is what these organizations live or die on, they are forced to execute at a much higher level much more quickly, lest they risk complete business failure.
Cost. Recruiting is expensive, especially when its for something like AI talent that is currently in high-demand from the tech sector, which has a very mature recruiting process for these types of positions. Furthermore, even when hired, in-house AI talent can turn into a recurring cost that may not consistently yield a positive ROI. Beyond this, there is also the general administrative burden that these teams bring - choosing product directions, updating technology stacks, and dealing with turnover all become cost centers that organizations have to absorb when building in-house. Organizations will have to weigh the cost of maintaining these teams with the potential cost associated with buying these solutions, and for each organization, this is likely to be a little different.
Time. Between the quality required and the cost associated with the resources needed to build that quality, lots of time is spent putting these AI assets together. And for companies looking to leverage efficiencies from AI sooner than later, this can lead many to lean towards working with a vendor.
The Hybrid Option: Outsourcing Only the Building
The third option that we see is one where companies will outsource the work of developing a solution to a third-party but own the product of the work. This is meant to allow companies to obtain the benefits of in-house solutions - customizations, company-specific quality, etc… - without the same, large upfront investment required internally to get these efforts off the ground.
This may help get companies to realize value sooner, but they should either feel comfortable with a static solution that will not evolve without additional investment or develop a plan to maintain and grow the project, since this approach still doesn’t solve for the long-term cost associated with an AI team to maintain these systems or upgrade and expand those systems as the underlying technology advances. But for many organizations looking for a quick start, this can be a helpful route.
The main consideration to be wary of in this case is related to the technology handoff. Typically, it’s easier for the team that created a software solution to maintain that software solution just due to their familiarity with the system itself. Ensuring that the engineering team responsible for maintaining a project after initial development is complete are well-versed in system architecture, code bases, package versions, and more are key to ensuring the system continues to function as intended.
Conclusion
Choosing the right path for AI integration in the life sciences depends on various factors, including budget, expertise, and the level of customization required. And depending on how each life science organization is constrained by these various factors, the answer will change. The goal of this post is to give an overview of the thought process that many life sciences organizations that we work with and see today are thinking about this problem.