Best practices

Build vs. buy: should you write your own liquid classes or adopt a shared catalog?

Every lab decides whether to develop liquid classes in-house or start from a shared catalog. Here is an honest look at the real costs of each.

Sooner or later every automated lab faces the same quiet decision: do we develop our liquid classes ourselves, from the empty editor up, or do we start from something someone else has already built and validated? It rarely gets debated openly. It happens by default, usually in favor of building, because the first class feels quick and asking for help feels like admitting you could not do it. But a liquid class is not a one-time cost. It is a thing you maintain, validate, and re-derive as instruments and people change, and the honest comparison has to count all of that, not just the afternoon it took to get the first version working.

This is a clear-eyed look at what building and buying actually cost, so the decision can be made on purpose. Neither answer is always right, but the reasons that should drive it are often not the ones that do.

The true cost of building in-house

Writing a liquid class from scratch looks cheap because the visible cost is the time to fill in the parameters. The hidden costs arrive later and are larger.

  • Development time: the real work is not entering numbers, it is the iterative testing and tuning to make a difficult liquid deliver correctly, which can take days for a demanding reagent.
  • Expertise: doing it well needs someone who understands how liquids behave and how the parameters interact, and that knowledge often lives in one person who eventually leaves.
  • Maintenance: a class is not done when it works; it has to be revalidated after service, moved to new instruments, and kept consistent as the lab grows.
  • Rediscovery: without good records, the next person re-derives what the last one already knew, paying the development cost again.

What a shared catalog gives you, and what it does not

Starting from a shared, validated catalog changes the starting point from a blank form to a class someone has already made work for a similar liquid. That is a real head start: the difficult reasoning about a viscous or volatile liquid is already encoded, and you begin from something close rather than something empty. What a catalog cannot do is know your exact instrument, your tips, and your ambient conditions. So buying does not remove the verification step; it removes the invention step. You still confirm the class on your hardware, but you are checking and adjusting rather than discovering from nothing.

The question that should decide it

The useful question is not which is cheaper in the abstract but where your effort is best spent. If a liquid is genuinely unusual to your work, something proprietary or novel where no prior calibration exists, then building is not a choice, it is the only option, and the effort is warranted. But if you are calibrating water, DMSO, glycerol, serum, common buffers, the liquids that thousands of labs handle every day, then building from scratch means solving a problem that has been solved many times over. Spending your best people on re-deriving a water class is a poor use of scarce expertise.

There is also a reproducibility argument that build-in-house tends to lose. A class developed privately is legible only to the lab that made it, and often only to the person who made it. A class adopted from a shared, documented catalog carries its reasoning and provenance with it, which makes it easier to audit, to transfer, and to hand to the next person without a briefing.

Building a liquid class from scratch for a common liquid is not thrift, it is paying again for something the world already solved. Save the from-scratch effort for the liquids that are genuinely yours.
Piptera

Notes on pipetting calibration, liquid classes, and building an open, vendor-neutral catalog for every liquid handler.

© 2026 Piptera. Built for labs.