

Spreadsheets and shared drives work for sample tracking right up until they don't. Volume and time drive the breakdown, whether you're a 3-person start up, or a 60-strong research team. A 96-well plate from a single high-throughput run can mean analysing ninety-six separate data points to determine which to take forward, then reliably linking that decision back to the physical sample(s) in question. A spreadsheet holds the data fine. But once volume climbs, the connection between a result and the sample behind it starts to break. We recently spoke to a team that were only weeks in, and they were already stuck on exactly this.
You can track sample location in a spreadsheet. What separates real sample tracking software from a glorified inventory list is everything else: full chain of custody and lineage tracing: what a sample is, how it was made, what it's been used in since, and who's handled it, plus linking inventory levels to the same record and retaining enough structure to reconstruct a sample's history months or years later. We've covered what this requires in more detail in our guide to choosing a LIMS for a small lab.
Take an arrayed CRISPR screen: one gene knockout per well across a 96-well plate, testing which genes affect a specific phenotype. For any of this to be usable later, each well's result needs a traceable path back to which gRNA construct was in it, which cell line and passage it came from, which reagent and media batches were used, and how that specific plate and well relate to its replicates. A plate reader exports results as a grid of well coordinates, but that context doesn't import automatically into Excel; someone has to match the grid against a separate plate layout by hand to know which gene was in each well. That's a manual step, and a mistake just waiting to happen; a rotated plate, a miscounted line, or an outdated layout sketch, and every well ends up attached to the wrong gene. Run that screen with several replicates, and each one needs its own layout to be tracked correctly against its own raw export, but also linked to the other replicates in the same screen, so that a results can be compared across replicates. Once a well is flagged as a hit, that whole chain; gene, construct, cell line, batch, plate position, needs to hold all the way back to a specific tube in a specific freezer box, since that's what gets pulled for validation.
If a gene name drifted along the way, this introduces even more errors. A 2016 study in Genome Biology found that Excel's autocorrect had converted gene names into dates in roughly a fifth of published genomics papers with supplementary Excel gene lists, with SEPT2 becoming "2-Sep," MARCH1 becoming "1-Mar"[1]. The problem was serious enough that the official gene-naming body renamed the affected genes in 2017 specifically to stop it happening. Once that link has broken, someone has to work backward from a hit to the right tube by hand: checking plate maps, freezer logs and old notes against each other, with no guarantee the trail is still complete months later.
High throughput experiments aren't the only ones where proper sample management matters. For example, a single transient transfection, with one plasmid, one cell line, and one readout is about as low-throughput as an experiment gets, and nothing about running it demands special record-keeping. In this case, the risk comes from how much time might pass before a problem surfaces. For example, when a reviewer asks you to repeat the experiment three years later, a colleague wants to build on the result in their next project, or (worst case) the result ends up mattering for a patent dispute, where the exact record of what was actually used becomes evidence. At this point, you need to be able to detail which version of the plasmid was actually used (since most labs hold more than one version of each construct, and "the GFP plasmid" isn't a specific enough answer), which batch of that prep, what passage the cell line was at, which lot of transfection reagent, and whether the original construct is still in the freezer or has been used up since. Tracking any of that in the moment takes no real effort. Reconstructing it years later is another matter entirely.
Lab Thread is built to hold up against both kinds of failure: the volume problem and the time problem. Every plasmid, construct and sample has its own identity in the system, with batch, passage, lineage and stock levels captured as part of the same record the work lives in. Nobody keeps a separate spreadsheet in sync by hand. Plate data imports match against a defined layout automatically, and several plates from the same screen stay linked as one body of work rather than scattered across files to cross-check by hand. This work happens once, at the point of logging, and holds up whether "later" means the next well on the same plate or a question that comes up three years on. See how it fits into the full platform on our LIMS page.
Standalone lab specimen tracking software can work well if all you need is location and basic history. Most labs find they also want that sample data connected to their ELN, molecular biology work and project tracking, rather than sitting on its own. If you're weighing that trade-off, we've covered which ELN is best for your lab in more detail.
There's no fixed team size or budget where this becomes worth it. The real signal is volume or time, the same two problems covered above: either too many samples moving at once for a spreadsheet to hold reliably, or too much time passing before a record needs to be trusted again. If either is starting to happen, the spreadsheet is already the more expensive option, you just haven't noticed it yet.
Ziemann, M., Eren, Y. & El-Osta, A. (2016). Gene name errors are widespread in the scientific literature. Genome Biology, 17, 177. https://doi.org/10.1186/s13059-016-1044-7