Skip to content
YDYavar DContact

MesoLab · Introduction

Introducing MesoLab Analytics

Why I am building a guided, offline analysis environment for real wet-lab workflows—and why the project starts with the decisions around the data, not only the final graph.

Most laboratory analysis does not begin with a clean dataset and a perfectly documented statistical plan. It begins with a measurement file, notes about the plate, a few decisions that still live in someone’s head, and the pressure to turn all of that into a result that can be explained to another person.

Spreadsheets are often the natural tool for this work. They are available, flexible, and familiar. But the same flexibility makes it easy to hide important steps: which wells were controls, how values were normalized, why one point was excluded, or whether an IC50 estimate actually came from a trustworthy fit.

MesoLab Analytics is my attempt to make the full reasoning path visible—from imported measurements to a report that still contains the scientific context.

Where the idea came from

The project grows from my biotechnology studies and practical work in a translational mesothelioma research environment. My thesis work involved Nintedanib and autophagy inhibitors across two-dimensional and three-dimensional models, supported by viability assays, Western blots, and flow cytometry.

That experience made one problem especially clear: the graph is only the last visible part of a much longer process. Before a curve can be trusted, the user has already made decisions about the plate layout, blank and control wells, replicate spread, missing measurements, normalization, and fit quality. Generic analysis tools often assume those decisions have already been handled correctly somewhere else.

A seven-step workflow

MesoLab currently organizes drug-response analysis into seven explicit stages:

  1. Import the measurement file and recognize its structure.
  2. Define the plate layout so wells, controls, concentrations, and conditions have meaning.
  3. Run quality checks before transforming the values.
  4. Normalize using selected control logic and visible assumptions.
  5. Fit curves with a four-parameter logistic model and diagnostic information.
  6. Compare cell lines, treatments, and experimental conditions.
  7. Export the results together with enough context to understand how they were produced.

The goal is not to force every experiment into one rigid template. It is to provide a clear default path while keeping scientific decisions reviewable.

Quality control should be a workflow

Many tools treat quality control as a warning icon shown after the analysis. I want it to be a real stage of the work. A suspicious edge well, inconsistent replicates, a missing control, or a fit that never reaches a stable lower plateau should not disappear behind a polished chart.

MesoLab therefore aims to show what the software noticed, what the user decided, and which warnings remain attached to the result. The software can assist with detection, but it should not silently rewrite the experiment.

Designed for the person at the bench

The intended user should not need to know Python, understand a dataframe, or reconstruct a multi-sheet workbook. The interface needs to be approachable for researchers who know their biology but do not want analysis software to become a second research project.

This also means avoiding an interface that assumes perfect eyesight, perfect technical confidence, or unlimited time. Clear language, large controls, sensible defaults, and visible consequences are not cosmetic details. They are part of whether the tool is usable.

What exists now

The current prototype focuses on the drug-response workflow: XLSX import, plate mapping, quality control, normalization, four-parameter curve fitting, comparison, basic statistics, and export. Western blot measurement workflows are planned next, followed later by combined analysis views.

MesoLab is still in active development. This blog will document not only completed features but also rejected approaches, interface changes, and the scientific assumptions behind them. The case study can show the polished direction; the devlog should show how the project actually gets there.