WHY

Why this pipeline.

Why DidemBio exists, why it's built the way it is, and the lines it won't cross.

WHY THIS EXISTS

For most labs, the bottleneck is no longer the bench. It's the analysis.

A talented student loses months to a framework that keeps shifting under them; a PI hands the data to a service and waits on a deck that doesn't answer the question they asked. The reason isn't that the analysis is hard; it's that the existing tooling assumes you have a bioinformatics team.

Most labs don't. They have a question, a dataset, and a deadline. So we built the analysis layer a lab would build for itself, if it had the time: one workflow per modality, the same shape across all of them, documented analysis settings, and a Methods paragraph you can review and adapt for your manuscript.

DidemBio is the analysis layer your lab would build for itself, if it had the time.

It is opinionated by design. There are not fifty parameters to tune. The analyses we ship are the ones we are willing to defend in peer review, and the data your lab actually generates, transcriptomic or cytometric, runs through one layer instead of two ecosystems and a separate vendor. If your data needs something the pipeline does not do, you ask. We answer.

WHY THIS PIPELINE

The tooling assumes you have a bioinformatics team. Most labs don't.

DidemBio is opinionated by design: one workflow per modality, the same shape across all of them, and a report you can defend in peer review.

01
Documented analysis settings.
Each workflow uses defined analysis settings. The report describes the methods and software used, so you can review how your results were produced.
02
A Methods paragraph that goes in the manuscript.
Every run writes a paste-ready Methods paragraph with cited defaults: not AI-generated prose, but a slot-filled template grounded in the exact tools and versions the run used.
03
No AI prose in the report.
Until we can guarantee what a language model writes about your data is true, it does not go in a deliverable you might cite.
04
Your data never trains a model.
Your counts, your FCS files, your matrices: none of them are training fuel. No academic loophole, no research exception.
05
Upload, don't install.
Hosted compute. No environment to manage, no version drift. Bring the data; the layer does the rest.
LINES WE WON'T CROSS

A product is the sum of what it refuses to do.

These are not roadmap items waiting to flip. If any of these lines ever change, we'll say so on this page.

01
An AI chatbot writing your report.
Until we can guarantee that what a language model writes about your data is true, it does not go in a deliverable you might cite.
02
A "free tier" funded by your data.
Your counts, your FCS files, your matrices are never training fuel. No academic loophole, no research exception. Never.
03
A workflow you fork to fix.
A figure that cannot be re-rendered from the same input is a figure that cannot be peer-reviewed. If the pipeline doesn't handle your data, you ask and we answer. Forking is not a feature.
04
A pricing page that needs a sales call.
Pricing should be predictable enough that a grant committee can read it. No sales call, no quote, no per-seat tier: the whole table is on one page, and the number you see on the upload screen is the number you pay.
05
A roadmap of fifty integrations.
Our surface is short on purpose. The analyses we ship are the ones we are willing to defend in peer review.