You should buy software too

Last week, I wrote about an open source project called Foam meant to help biotech teams build custom applications to fill in the gaps between their other software. But there’s one thing I should be very clear about - Foam is meant to make building software easier in the same way that saw mills made building a house easier: You no longer have to hand cut each piece of wood, but you still have to do a lot of building. So Foam should only be a last resort when you can’t buy software that does what you need. This week I want to argue that those situations are becoming and will continue to become much less common. (I hope Foam can help bridge this transition.)

For all the reasons not to build your own software, Kaleidoscope has an excellent blog post on the subject. And while you may be skeptical of a software vendor telling you why you should buy software, the post is 100% spot on. (I also really like what Kaleidoscope is building, which is why I keep plugging their blog - this is not a paid endorsement.)

As for why buying software is getting better, I think there are two closely related shifts in biotech teams that created an initial need to build internally, but that software vendors are now responding to. The first, which I’ve written about before, is that as biotechs build internal data teams, they need to manage data in ways that traditional ELNs and LIMS don’t facilitate. The second is that as there are more individuals inside biotechs who are both scientifically minded and technically engaged (the line between IT and the business is vanishing) they have different expectations for how they should be able to design and customize their software.

Today, I want to focus on this second one.

It’s true that most traditional biotech software is highly customizable, but there’s often an expectation that the customization will be done either by the vendor or by an IT contractor with existing expertise in the product. In this situation, it’s OK if configuring the software is unintuitive because the expert will still know what to do. And it’s OK if configuring the product requires a lot of clicking around in a UI because an IT contractor is less likely to prefer writing code.

This make sense when there’s a clear divide between scientific users who don’t want to think about the technical details and an IT department that doesn’t want to design the model. There’s something nice about being handed a fully functioning system - that’s why you buy an existing house whose layout isn’t perfect over building a new one with a better layout (even though sawmills exist).

But for a user who has both the scientific and technical expertise, it’s going to be faster and less frustrating to implement the configuration themselves than to try to explain it to an IT contractor. And they’re more likely to prefer writing code because their technical experience is from data science/software engineering instead of IT. So they’re going to want software that’s more intuitive to configure if you’ve never used it before, and more oriented towards coding instead of clicking around a UI.

A really interesting case study in this is the difference between Tetrascience and Ganymede, both of which are platforms for transferring data from lab to Cloud. I would argue that they’re not direct competitors because their approaches target very different customers. Here, the customization is all around building connectors for specific lab instruments. Tetrascience takes the approach of building all the connectors internally, so users just have to pick them off a list. Ganymede takes the approach of letting users write their own scripts. The two classes of users I described above will have very different and very strong preference for one or the other.

Five or ten years ago, most biotechs had a clear divide between science and IT, so software vendors built for those companies. Then as hybrid biotech teams started to crop up, there wasn’t purchasable software that they could configure the way they wanted, so they built instead. Today, however, most of the biotech software startups are building for this later group. In fact, a number of them are veterans from this later group. And as the market of hybrid science/tech buyers increases, the number of startups serving them will follow suit, giving biotech teams even less reason to build anything. Maybe some of these teams will use Foam to prototype this next generation of software but no matter what, it’s going to happen.

Scaling Biotech is brought to you by Merelogic. We design data models and infrastructure that help early-stage biotech startups turn their AI/ML prototypes into tangible impact. To learn more, send me an email at jesse@merelogic.net