Why biotechs should buy more of their software.

The software-for-bio landscape looks very different today than it did several years ago. At Kaleidoscope, we’ve spoken to numerous biotech companies that were forced to make the expensive decision to build in-house software but wish they hadn’t needed to. In this post, we outline what is so expensive about building your own tooling and why it’s best to avoid it when possible. As always, if anything here resonates with you, please reach out!

Summary points

• Time-and-money-intensive: Building internal software is expensive, both in terms of time and money to create a usable tool, and in terms of the complexity in maintaining that tool over time.
• Expensive indirect costs: As an R&D company, your valuable resources should be used to advance your core IP; building internal tooling is a big distraction from doing the science that matters.
• Adapting existing software: While your workflows may feel very unique, the abstracted problems are much more ubiquitous. Modern external software can get you 90% of the way and be adapted for the last mile, for far less time and money, and for a far better product experience.

In our previous post, we mentioned that many biotech companies have been forced to build their own internal software. Historically, attempts to stitch together generic, off-the-shelf tools, built for entirely different use-cases, failed. Teams were left with big gaps between the problems they faced and the software at their disposal. What these companies unfortunately had to learn is just how expensive it is to build an internal stack — when we speak to these teams, we regularly hear that they wish they hadn’t needed to pay this cost to achieve their goals.

With the evolution of vertical software, there are increasing opportunities to buy fit-for-purpose tools that can be adapted or extended to fit unique needs. Teams are now in a position to save significant time and money by purchasing rather than building. But why is building internal tooling painful? Let’s start by mapping the general journey a company may have historically had to take.

Often, it begins with what looks like a simple project: “We want to track the statuses of certain interrelated projects and easily map relevant data flows. There isn’t good software to support this — let’s get a couple of engineers to design a custom dashboard!”. The first common mistake is underestimating how hard it is to build good, usable software that works how you expect it to. You need to be thoughtful about numerous things: how you’re architecting the software, what objects and relationships you’re defining, who your end-users are and how they will interact with the interface. Getting to a point where this internal tool can reliably work as needed, and is accessible to the various end-users you had in mind, will take significantly longer than initially estimated.

Then, there’s a major consideration that people who haven’t built software often miss: the cost of maintaining a tool. This goes well beyond the inevitable bugs and failures you’ll uncover through usage, and extends to how you will use the tool. Companies and their needs are dynamic. Building a custom tool is not a one-time project — your needs will change, which means the demands you have of your tooling will also evolve. Maybe that dashboard you first built will need to support new data types, or you’ll need to customize the views you display based on changing end-users. Now you need people in charge of both generally maintaining the tool and of adapting it for new use-cases, over many years. And what happens if the people who initially built the first version have changed roles or left the company?

Effectively, by building internal tooling that you plan on actively using, you’re committing to running a software company within your biotech. Not only is this extremely expensive in terms of direct costs, but it’s also a big distraction from the work that matters. As a therapeutics company, for example, your focus is on doing great science: generating results, testing hypotheses, advancing/de-risking your assets, and ultimately working towards developing and commercializing drugs that will treat disease. Your team is built around this objective and hires are made from the perspective of bolstering the company’s core competency. Even if you’re hiring engineers or data scientists, their expertise most likely lies elsewhere — they are likely not product managers, designers, or web application or product engineers. Unless the software is part of your core IP, spending time and money refocusing people to build internal tooling is the wrong thing to do.

These costs are particularly pronounced when the internal tools need to work within a highly technical, complex, and data-heavy context like R&D. When we asked experienced, software-savvy teams that have done this to quantify it for us, we commonly heard that it took them several engineers and a few years’ worth of time to get a tool to a working state. That’s ~$1M in operating cost per year of work (these are companies in the 10-30 person range — costs skyrocket when larger teams are involved) for a janky tool that’s a pain to use. Add on maintenance over time, and you’re left with a much bigger price tag.

What’s worse is that companies are frequently reinventing the wheel when building in-house software, without realizing it. “But our biotech is unique. We are doing cutting-edge work that no one else is; our workflows and therefore software needs are different.” While this statement is true in the sense that a set of work might be unique, you can still use a well-abstracted software to solve for your needs. Even if off-the-shelf tools don’t match your work 100%, if you can find something that matches 90% and is extensible/adaptable for the last mile, it’ll be far cheaper and more scalable. This is especially true when factoring in that you won’t ever truly be ‘done’ building your own custom tool, so the time commitment to maintain it far exceeds the time needed to extend an existing, well-designed piece of software.

This evolution of going from building internal tools to leveraging off-the-shelf options similarly happened in the software development world. There was a time, not that long ago, where software companies had to painstakingly host files, run servers, and create UI libraries. But then, tools like S3, ECS, and React emerged and were adopted by these teams, drastically accelerating the rate at which software products got shipped. While the analogy may not be perfect, the two worlds are similar — by using existing tools, you are able to share the costs (design, infrastructure, security, etc.) with other customers, and put more dollars and minutes towards advancing your own IP.

At Kaleidoscope, our belief is that R&D teams are increasingly poised to go through a similar leap in productivity, if they could spend less time building the ‘software plumbing’ themselves and instead focus more on their core science. What was once necessary to build in-house because of a lack of alternatives is no longer the case, with the emergence of software tools supporting biotech. Our goal with Kaleidoscope is exactly that: deliver a powerful, intuitive, and extensible product that R&D teams can easily leverage and adapt, so that they can focus their attention on the science. It’s why we raised the money we raised to start the company in the first place, and why we built a stellar team with deep expertise in science x product engineering to get the fundamentals right.

If you want to chat more about anything we wrote, or you’re interested in finding a way to work together, let us know!