There is a version of choosing lab software that involves a requirements matrix, three vendor demos and a committee. If you have that, this guide is not for you. This is for the lab where the person evaluating the electronic lab notebook is also the person running the experiments, and the evaluation has to fit around them.
The good news is that the shortlist collapses quickly, because one question eliminates most options before you look at features at all.
A PI, postdoc or lab manager choosing an ELN for a group of roughly two to twenty people, with no dedicated IT support and no server of your own. It applies whichever system you end up with, including ones that are not us.
The question that eliminates most of the list
What has to be installed, and on what machine?
Ask it first, and ask for specifics. "It's cloud-based" is not an answer — plenty of cloud systems still want an agent on a machine to collect instrument data, and that machine is the one you cannot touch.
If anything at all has to be installed on the instrument PC, the real cost is not the software. It is that the instrument PC is often running an operating system a decade old, is not allowed on the network by the institution, is under warranty conditions that forbid changes, or is shared with two other groups who will notice.
There is a whole guide on the instrument PC problem, because it is the single most common place these projects die. It is here.
The four questions after that
1. What happens to our data if we stop paying?
Ask for the export format by name, and ask whether the exported files open without their software. "You can export to our archive format" is not an answer either. CSV, PDF, original files in a folder structure — those are answers.
Then ask the harder version: if we stop paying, does anything have to move? A system that holds your files has to give them back. A system that only links to files where they already are has nothing to give back, which is a different and better position to be in.
2. What happens to what we already have?
Paper, OneNote, a decade of folders on a shared drive. A notebook that only holds the future leaves you keeping two records, and that is the failure mode. Ask what import covers and whether it is on the plan you can afford, not only the top one.
3. Are earlier versions kept when an entry is edited?
And can an administrator clear that history? If it can be cleared, the record cannot show that an entry existed before a conclusion was drawn — which is most of what a countersigned paper page was doing for you.
4. Where does it run, and where do prompts go?
If the system has an assistant, ask which account the prompts go to and whether your text is used to train anything. For an Indian institution this is a question your research office will eventually ask you, so it is easier to have the answer before they do.
What not to evaluate on
Three things absorb evaluation time and predict almost nothing.
Feature counts. Every ELN has more features than your lab will use. The list tells you what the vendor built, not what you will touch. Ask instead what the first week looks like.
Integration counts. "Two hundred integrations" means very little when the instrument you care about is a 2013 plate reader that writes a proprietary file to a folder. Ask specifically about your instruments, by model, and treat a confident general answer as a warning.
The demo. A demo shows you the system with clean data, entered by someone who built it. It is a sales artefact. It tells you the software exists and roughly what it looks like, which you could learn from screenshots.
woodle points at the folder your instrument already writes to, and nothing is installed on the instrument PC. Files stay where they are, so if you stop, nothing moves. We would rather you ask us the five questions above than watch a demo.
See how instruments work →The trial that actually tells you something
Do not trial with new work. New work is going well, everyone is enthusiastic, and every system looks fine for a fortnight.
Trial with a study you already finished. Take a project where you already know the answers — where the figure is published, the files are somewhere, and you remember roughly how it went. Then put it in and see whether the record holds together better than the version you have now.
This works because you can check it. You know what the right answer is, so you can tell whether the system gets you there. And it takes an afternoon rather than a term.
The specific test: pick a number in your own published figure and try to get from the record to the file that produced it, without opening anything else. If you cannot, that is the answer.
Cost, when the budget is a grant line
Two things are worth knowing before you look at any price list.
First, per-seat pricing behaves badly in a lab, because the people who most need to be in the record — the student on a six-month rotation, the collaborator who did one experiment — are the ones you will be tempted to leave out to save a seat. Ask what a rotating student costs.
Second, a free plan is only useful if it is a plan rather than a trial. Ask whether it expires, whether it holds real data volumes, and whether export works on it. A free tier you cannot get your data out of is a trap with a longer fuse.
The checklist
Work down it. Tick as you go — this list remembers your progress while the page is open.
What you are actually buying
Not storage — you have storage. Not search, really; a well-named folder tree searches adequately.
What you are buying is that the connection between a result and the evidence behind it survives the person who made it. Every question above is a way of testing whether a given system will still be doing that in five years, on a budget you can defend, without an administrator you do not have.
If a system fails the first question, none of the others matter.
This checklist is free to copy, print, or paste into your lab's own documentation. No attribution needed and no signup — if it's useful, use it. It is written to work against any vendor, including us.