Sequencing produces a lot of data. Getting that data through the pipeline and into a result that people can use takes engineering.
We build and maintain the software between the sequencer and the final result. That includes NGS pipelines in Nextflow, WDL and Snakemake, variant calling with GATK, the reference databases and applications around them, and the testing needed to keep runs reproducible. We work with genomics companies, research groups, and diagnostics labs.
BWA aligns reads, GATK handles variant calling, and SAMtools is used for working with the resulting files. We put these and other tools together into production pipelines.
The pipeline has to run the same way across samples, whether it is on a cluster or in the cloud, without someone having to watch every run. And if someone asks two years later how a result was produced, the team needs to be able to show what happened.
That is the part we build. The input might be raw reads. The output might be a VCF, an annotated report, a database record for analysts, or an application a clinician uses.
tool versions pinned in containers · clear inputs and outputs between stages · reference samples run again whenever the pipeline changes
Nextflow, WDL and Snakemake. We work with the workflow engine the team already has.
A team running Cromwell and WDL can keep WDL. A lab with years of Snakemake rules can keep Snakemake. We care more about how the pipeline is built, tested, and maintained than about making everyone use the same engine.
For new pipelines, we usually recommend Nextflow. nf-core gives the team a tested starting point, and the same workflow can run on a laptop, an HPC scheduler, or AWS Batch. GenXFlo also lets a scientist put a pipeline together without having to wait for an engineer.
A pipeline that runs once is a script. If you need the same result two years later, it is infrastructure.
This is where teams tend to lose time. Tool versions change. Reference genomes get updated. A dependency inside a container can change without anyone noticing. The pipeline still runs, but the result can move slightly. Sometimes nobody notices until an older result is compared with a new one.
Every tool version pinned in a container.
Each stage defines its inputs and outputs, so a bad file does not quietly move through the rest of the pipeline.
Reference samples with known results are run again whenever the pipeline changes, as part of continuous integration.
Raw inputs are retained so an output can be traced back to the exact file and software version that produced it.
It is the same discipline we use when a pipeline needs to stand up to validation or a submission.
We usually come into a project in one of three ways.
A pipeline that works, but does not scale
We take the existing pipeline, make the runs reproducible, and add the tests and documentation the team needs to maintain it.
The science is there. The software around it is not.
We build the web application, APIs, reference databases, and job orchestration as part of the client's engineering team, sometimes for years.
A pipeline that has not been built yet
For a new assay, panel, or data type, we will usually use Nextflow and nf-core components where they fit. Validation runs alongside the development work.
Teams range from one engineer joining an existing group to a dedicated team of five or more. One genotyping platform engagement started with one engineer and grew to four. The mutation calling platform had a team of five.
Who do we do this for?
Our genomics clients include platform and instrument companies, cancer diagnostics companies, the research organisation of a large pharma company, and oncology data companies. Some have large bioinformatics teams and need additional engineering capacity. Others have a small team and need us to cover much more of the software work.
The science belongs to the client. Our job is to build the software around it and make sure it can run at the required scale and under the required controls. We do not name clients on this site. Where we describe an engagement, the client details have been removed from the case study.
NGS pipeline development
Designing, building, and hardening the workflow from raw sequencer output to analysis ready data, with reproducibility and scale treated as requirements rather than afterthoughts.
Variant calling and analysis
The step where a sample's differences from a reference genome are identified, filtered, and annotated, and where germline and somatic workflows diverge.
Statistical analysis for biological data
What happens after variants and expression values exist, the layer that turns a table of numbers into a defensible finding.
Companion diagnostics
When a test decides who receives a therapy, the analysis behind it carries validation and traceability obligations research work does not.
GenXFlo
This work also connects with GenXFlo, our tool for designing and running Nextflow workflows visually. Teams that want to build pipelines faster without a dedicated pipeline engineer for every change should read that page alongside this one.
Read about GenXFlo
A modular mutation calling pipeline, alignment through reporting, validated stage by stage in TypeScript, with 98 percent automated test coverage on the web application.
Read the case study →End to end engineering for a custom genotyping assay design platform: Nextflow pipelines, NCBI reference databases, Angular and .NET. Time to market up 50 percent.
Read the case study →Questions people ask
Do you work in Nextflow, WDL or Snakemake?
All three. New pipelines are usually Nextflow. Existing pipelines stay in whatever engine they are in. The reproducibility practices, pinned containers, staged contracts and reference sample tests, are the same regardless of engine.
Can you take over a pipeline someone else wrote?
Yes. It is a common part of the work. We start with a set of reference samples with known outputs, then use those results to check that the pipeline continues to produce the same answers as we make changes.
Do you build the web application as well as the pipeline?
Usually. Most engagements include the application researchers use to configure runs and review results, the APIs connecting it to other systems, and the databases underneath. The pipeline is rarely the whole product.
What is GenXFlo and do we have to use it?
GenXFlo is our tool for building and running Nextflow pipelines visually. We use it on engagements where it makes the work faster or easier for the client's scientists to maintain. It is not a requirement.
How do you handle validation for clinical or regulated use?
The pipeline is built with validation in mind from the start: pinned versions, traceable inputs, automated tests with kept evidence. When the work is headed for a submission, our regulatory and validation team runs the validation alongside the build.
Have a pipeline that needs to scale, move, or pass validation?
We work with genomics and bioinformatics teams on pipeline development, platform engineering, and the software around the analysis.
Start a conversation