Close

Build vs. Buy: Which is the Right Informatics Strategy for Your Lab?

Are you trying to decide if your lab should build its own custom software, buy off-the-shelf software (knowing you’ll inevitably have to customize it), or just keep stumbling along with Excel and paper-based tracking? The answer to this question will ultimately depend on your short- and long-term information system (informatics) strategy.

How do you devise an informatics strategy? There are several options to choose from, each with its pros and cons. In their paper discussing the factors affecting buy-vs.-build decisions, Patrick Hung and Graham Cedric Low suggest that “effectively managing buy vs. build could be the key to managing IT.” For labs, the strategy you choose is particularly important. It could make the difference between success or failure, or, at the very least, impact your rate of innovation.

Given how often we have run into labs needing to shift their approach from build to buy or vice versa, we recommend using a decision framework that examines the options in the context of molecular diagnostics laboratory requirements.

Building your own custom software

Building the software (often called do-it-yourself “DIY” software) might sound ideal at first, especially for a sector as under-served by commercially available options as molecular diagnostics is. You’ll get exactly what you want, based on your own requirements. But before deciding to do this, ask yourself the following questions:

  • Is your use case unique enough that it warrants the time and expense of building software from scratch?
  • Is there an existing software product that could get you to at least 60% of where you need to be? Note that 60% is generally the point at which it’s considered worthwhile using off-the-shelf software.

If you do want to build software from scratch, you have two choices:

  1. Building in-house. Consider whether your lab has the expertise already in-house or if you’ll need to hire staff with the right skills. Also, remember to include the time and cost of building the internal competency required in hiring, training, and retaining developers in an extremely competitive talent market.
  2. Partnering to build. This means working with a software development firm to custom-build and maintain the software.
If you are considering one of these options, don’t forget to factor in the risk of the developers (in house or with the external partner) leaving the team. In our work as an external partner building custom lab informatics systems, we have worked hard to devise methods to mitigate this issue; for labs, these methods would likely be cost-prohibitive to implement.

Also, you’ll need to ensure that the software can handle data in accordance with a variety of regulations, such as HIPAA, CAP, or CLIA — so you additionally need to make sure the developers are specifically trained in this area.

Buying software off the shelf

Buying commercial off-the-shelf (COTS) software is the other way to go. But be aware that, in almost all cases, you will very likely need to make extensive customizations since a truly out-of-the-box solution that works for molecular diagnostics labs does not yet exist.

In our experience, 50% of the total system cost comes from purchasing licenses for the COTS product, while the remaining 50% is spent on implementation and customization. Given that the threshold for build vs. buy is 60%, you can see how a DIY approach might win. For a breakdown of the types of software a lab needs, read our previous post.

If you do want to purchase off-the-shelf software, you have two choices for customizing the solution:

  1. Customizing in-house. Similar to building software in-house, you’ll need internal expertise to customize and maintain the software.
  2. Partnering to customize. This means working with a consultant to implement and maintain the COTS software, and build customizations and integrations. It’s a great option when you don’t have the internal resources or expertise required to implement your informatics solution, but make sure you choose the right consultant.

Additional factors to consider

Before making a final decision about whether to build or buy (and customize) software, we recommend developing and documenting your requirements so that you know exactly what the software needs to do.

Once you have a list of requirements, consider these other factors:

  1. Alignment with company strategy. If your stakeholders are not “all-in” with your decision, this can cause serious issues for the project down the road. For example, imagine your CTO decides to build software in-house, but leaves mid-project. If the new CTO doesn’t believe in the project and decides it’s not worthwhile, you could lose all the money and work you’ve invested. This is known as the value of risk.
  2. Scalability. Software plays a critical role in a lab’s ability to scale. Consider how many samples you are processing now and how many you want to be processing in 5 years. Will your software be able to handle that increase? Hung and Low suggest that for complex projects, using COTS software can provide benefits in terms of expertise and economies of scale, “even if used only as a foundation for further development or customisation.”
  3. Flexibility. Labs are constantly having to adapt and respond to changes in innovative ways (COVID-19 is an obvious recent example of this). Your lab software needs the flexibility to support these changes. We’ve worked with labs that previously chose to build their own software, which had “hard-coded” workflows that could not be modified or extended. The only workaround was to rewrite the code. Whether you build or buy, the software should be extensible.
  4. Rate of change capability: The reality of the modern lab is that assay revisions are being created constantly. Recent events have made it ever more clear that our software needs to keep up. Consider how well the chosen solution can integrate into a CI/CD pipeline and manage releases at scale.
  5. Complexity and scope of development. Molecular diagnostics labs have specific requirements due to complex workflows. You’ll need to consider: Do you have in-house staff or a partner with molecular diagnostics expertise that can build the complex software you need while ensuring it’s user-friendly and compliant with regulations? Or is there already an existing solution that you can work with? These are questions worth asking before you make a decision either way.

Relative costs of informatics options

As with any business decision, cost will also be a factor. Let’s look at the options and their relative costs.

Build Buy
Direct staff costs
(salaries)
In-house Partner In-house Partner
Capital costs
(IP purchases, big-ticket items)
$$$$ $ $$ $$
Implementation costs
(non-developer configuration)
$ $$$$ $$ $$
Maintenance costs
(updates and changes as organization continuously develops)
25% of capital costs YoY 25% of capital costs YoY Typically 20% of license + internal staffing Typically 20% of license + retainer for customized modules
Opportunity costs
(cost of taking staff away from core business functions to work on informatics)
$$$$ $ $$ $
Operational costs
(hosting costs, subscription fees per month)
$ $ $$ $

Resources for your software journey

Once you’ve decided whether to build or buy, and whether to work with a partner or do the work in-house, there are several things you should know to ensure you have the best experience.

If you choose to build software from scratch:
If you choose to buy and customize software:

We’ve worked with many clinical diagnostic labs and can tell you from experience that there’s no one-size-fits-all solution. However, if you’d like to talk through your options, we’re here to help.

Contact us to discuss your informatics strategy or if you have any questions about which is the right choice for your lab. Read the other posts on our blog for further insights.
Share this post:

Eban Tomlinson is the Head of Sales and Marketing at Semaphore Solutions. Eban leverages his deep technical informatics expertise combined with clinical genomics and genetics project experience to help Semaphore redefine the field of clinical laboratory informatics.