Questions, answered.

No. Microbiology is where our founder comes from, and it shows in how we work with any lab: we know what a run, a plate map and a failed control look like.

We build for life-science teams across molecular and cell biology, genomics, diagnostics, bioprocess and assay development.

Yes, and that is the usual situation. We set up what the tool needs to run, train the people who will use it, and hand over documentation written for scientists, not developers.

From your side we need one person who knows the workflow and can answer questions.

Usually not. Replacing a system your team already knows is rarely the best use of your budget.

We connect to it through its API, or its import tools where there is no API, and fill the gaps around it: the instrument that doesn't talk to it, the report nobody wants to assemble, the step that still lives in Excel.

Yes, and it is often the fastest place to start. We turn working R or Python scripts into tested, documented tools that anyone on the team can run, and we keep the science the scripts already got right.

Thirty minutes about one workflow: where the data comes from, where it needs to go, and who loses time in between. No slides.

You leave with a clear next step, whether or not we end up working together. If it's a fit, a written proposal with scope, timeline and a fixed price follows.

Yes. Core facilities and research groups face the same data problems as companies, often with less time to solve them. We scope the work to fit grant budgets and timelines.

You do. Once each stage is paid, the source code, the documentation and the IP created for you in it are yours, and that is written into the agreement.

Open-source components keep their own licenses. We don't resell a tool built for one client to another.

In your environment wherever possible: your cloud account, your servers, your ELN.

We build and test with sample or anonymized data when we can, and we only touch production data with your permission and for as long as the work requires.

Yes. We're happy to sign your NDA before you share anything confidential.

The first call doesn't need one: we only need to hear how the workflow runs, not what you are discovering.

Our focus is research and development work outside GxP.

If a tool may later need to enter a regulated process, tell us at the start: we'll design it with that in mind (audit trails, access control, electronic signatures, change history) and be clear about what formal validation would involve.

Software that sits between your instruments, your data and your people: data pipelines, analysis apps, bioinformatics workflows, sample trackers, dashboards and AI tools for documents.

If it involves lab data and a step someone repeats by hand, it is probably in scope.

Whatever fits your environment and your team. Typically Python and R for analysis, Nextflow or Snakemake for pipelines, containers for reproducibility, and web interfaces for the tools scientists use every day.

We deploy to your cloud (AWS, Google Cloud or Azure) or on your own servers.

You get the code, the documentation and a short training session for the people who use the tool.

After that you choose: run it yourselves, or keep us on a support plan for fixes, updates and new features as your workflow changes.

It depends on scope, so we price each stage as a fixed amount, agreed in writing before work starts. The first call and the written proposal are free.

Most teams start with one focused tool and grow from there once it has proven itself.

A focused tool, such as a pipeline from one instrument into your ELN, typically takes a few weeks.

Larger platforms are built in stages: you get a working version early and improvements every week or two. You'll have the timeline in writing before you commit.