Ask a bench scientist what software they use to manage their experimental data, and the answer is usually a list: an ELN for entry, a LIMS for sample tracking, a plate reader export that gets pasted into Excel, a shared Google Sheet for cross-run comparisons, and at least one Jupyter notebook someone wrote two years ago that no one is confident still works. The spreadsheet is almost always somewhere in that chain — not by design, but because it fills gaps that nothing else does.
This is not a complaint about researchers. It is a structural observation about how scientific software got built. Each tool in the stack was optimized for a single job: the ELN records what you did, the LIMS tracks what you have, the instrument exports the raw signal. None of them were built to talk to each other, and none of them were designed to answer the question a scientist actually needs answered at 11pm before a group meeting: "Across my last eight runs, is this condition consistently outperforming baseline, or am I seeing noise?"
How the Spreadsheet Became Load-Bearing Infrastructure
The spreadsheet's durability in research settings makes a certain kind of sense. It is the one tool that can ingest output from anything: CSV from the flow cytometer, copy-paste from the ELN, a VLOOKUP joining two experiment IDs. It is infinitely flexible and requires no IT provisioning. When a research team needs to move fast, the spreadsheet is always there.
The problem is not that spreadsheets are used for quick analysis — that is fine. The problem is when they become the connective tissue between systems that should be integrated. A typical data flow for a cell-based assay might look like: raw viability data exported from a plate reader, opened in Excel, manually keyed with condition labels from a paper printout, merged with a cell count from a separate LIMS export, cleaned of outliers by hand, then dropped into a shared folder with a filename like Exp47_cleaned_FINAL_v3.xlsx. Every manual step in that chain is a place where a transcription error, a version mismatch, or a forgotten update breaks the thread between a raw instrument reading and the conclusion in a PI's weekly report.
The version proliferation alone creates significant downstream cost. A study of data management practices in wet-lab environments regularly surfaces the same pattern: when you ask a team to reproduce results from six months ago, someone has to reconstruct which spreadsheet was "the real one" at the time of the decision. The answer is often unclear, and the time cost to reconstruct it is not trivial.
The Hidden Overhead of Integration Work
Consider a mid-size academic research group running CRISPR functional screens — say, eight to twelve researchers, high-content imaging, a sequencing pipeline, and manual dose-response curves done in Excel. The postdoc managing data integration is not doing that work because they chose to; they are doing it because no single tool covers the span from library design through to statistical scoring. The integration layer defaults to them, mediated by spreadsheets.
This is where the hidden cost is most real. It is not just the hours spent on data wrangling — which, in labs we have spoken with, commonly runs to 20-40% of a researcher's weekly time in data-heavy workflows. It is the cost of what does not happen: the experiment that does not get run because the last analysis took longer than expected, the discrepancy that does not get caught because cross-run comparison requires opening four files and manually aligning columns.
We are not saying spreadsheets are bad tools. For exploratory analysis, for small datasets, for a single scientist understanding their own data — they are perfectly reasonable. What we are saying is that when a spreadsheet file becomes the authoritative record of a decision, and when that record lives in a shared folder where version control is a naming convention, the organization has a reproducibility problem that compounds over time.
What Integration Actually Requires
The reason labs are still on spreadsheets is not that they have not heard of ELNs. Most growing research teams have at least one ELN deployment, and a significant fraction have tried a LIMS. The failure mode is not adoption — it is coverage. Each system covers its own domain and no further. The ELN stops at the edge of the instrument file. The LIMS stops at the sample. The analysis notebook stops at the last figure someone saved.
Real integration requires that the query "show me all experiments involving compound X at concentrations above 10uM where viability dropped below 50%" can be answered without opening a spreadsheet. It requires that a protocol executed last Tuesday can be diff'd against the one from three months ago to identify what changed. It requires that when a researcher runs a new analysis, the lineage of every input — which sample, which instrument run, which processing step — is queryable, not reconstructed from memory.
This is a data architecture problem as much as a software problem. The ELN-LIMS-scripts stack was never designed around a unified data model. It was designed around artifacts: the notebook entry, the sample record, the result file. Connecting those artifacts after the fact is the work the spreadsheet has been doing by default.
The Cost Is Structural, Not Incidental
One way to surface the real cost is to ask how much of a research team's reproducibility problem is traceable to tooling rather than experimental technique. In most labs, the answer is larger than expected. Failed reproductions in published research are commonly attributed to underspecified methods, but the underspecification is often downstream of the tools: if your protocol lives in a Word document, with parameters copied from a spreadsheet that no longer matches the one that produced the original result, there is no version of "better documentation practice" that saves you. The tooling has to change.
There is also an onboarding dimension. A new PhD student or postdoc joining a lab with a spreadsheet-mediated data stack spends weeks — sometimes longer — reverse-engineering how the pieces fit together. Which spreadsheet format does the plate reader export in? What column headers does the PI's analysis script expect? Where are the historical runs kept? None of this is documented, because the documentation is the spreadsheet itself, and the spreadsheet assumes you already know the context.
A Different Starting Point
The path forward is not to find a better spreadsheet or a better ELN. It is to start from the experiment as the unit of truth — not the file. When a protocol, its parameters, its inputs, and its outputs are captured as structured objects rather than documents, the integration problem largely disappears. The plate reader output does not need to be manually joined to the condition labels because both were recorded against the same experiment object at capture time. The analysis notebook does not need to manually import a CSV because the experiment's data layer is queryable directly.
This is architecturally non-trivial to build, which is why it has not happened through incremental ELN upgrades. It requires rethinking the data model from the substrate up — experiment as entity, protocol as executable specification, analysis as a step in a provenance chain rather than a standalone file. The spreadsheet fills the gap because the gap exists. Closing the gap requires building differently, not adding another integration layer on top of what is already there.
When we started building Cypher AI in 2025, the goal was exactly this: not another record-keeping tool, but a layer that holds the connective tissue the existing stack has always externalised to researchers. The spreadsheet will probably still be there — for exploratory work, for communicating with collaborators, for things that genuinely are one-off. But it should not be the glue holding a reproducible research workflow together. That is too important a job for a file.