Automated mutation calling for high throughput NGS data
A leading healthcare technology organisation needed a mutation calling platform that takes raw sequencing data and turns it into reliable variant calls for oncology research and personalised medicine. Sequoia built the secondary analysis pipeline, validated every stage of it in TypeScript, delivered the web application researchers run it from, and covered 98 percent of that application's workflows with automated tests.
Where does mutation calling sit in the NGS workflow?
Raw sequencing data does not tell you which mutations a sample carries. It is millions of short reads and a quality score for each base. Getting from there to "this tumour has a mutation in this gene" is secondary analysis, and it is where most of the computational risk in a genomics product lives.
The stages are well known. What is hard is running them at throughput, on every sample, without a bioinformatician watching, and being sure that what comes out the end is right.
| Stage | What happens |
|---|---|
| Alignment | Each read is mapped to its position on the reference genome |
| Variant calling | Positions where the sample differs from the reference are identified and scored |
| Annotation | Each variant is labelled with the gene, the predicted effect and what is known about it |
| Reporting | The called and annotated variants are assembled into output a researcher or clinician can act on |
For oncology research and personalised medicine, a missed or spurious call is not a cosmetic bug. It changes what a researcher concludes about a sample. That is the standard the client set, and it is the standard our bioinformatics and genomics practice works to.
What did Sequoia build?
Three pieces, from a team of five engineers covering pipeline, application and test automation.
A modular secondary analysis pipeline
Alignment, variant calling, annotation and reporting, built as separate stages with defined interfaces between them. Modular matters here because stages get swapped. A new caller, a new annotation source, a new report format. Each can change without the others knowing. The pipeline takes raw sequencing data and integrates with the client's sequencing workflows on the other side.
Type safe verification of every stage
Each stage's inputs and outputs are declared as TypeScript types and checked programmatically. A result that does not match the contract cannot pass quietly into the next stage. This is a cheap discipline with a large payoff in a pipeline where a silent malformed output at stage two shows up as a wrong answer at stage four. It made the mutation calling logic more reliable and kept downstream interpretation consistent from run to run.
The web application, and 98 percent of it under test
Researchers configure runs and review called variants in a web application. Sequoia built a Cypress test framework that covers 98 percent of its frontend workflows. Every commit runs the suite in continuous integration, so a UI regression is caught the day it is introduced rather than the week it reaches a user. Manual testing load dropped to the residue the automation could not reach.
Why put automation first on a genomics product?
Because the alternative is slow and it is not safe. A mutation caller has a scientific core that changes rarely and an application around it that changes constantly. If every change to the application needs a manual regression pass, releases stretch out, and the pressure to skip the pass grows with every sprint.
Two layers of automation covered both halves. The TypeScript contracts guard the pipeline, so a change to one stage cannot corrupt what the next one receives. The Cypress suite guards the application, so a change to the UI cannot break a workflow a researcher depends on. Between them, a release is something the team can do on a normal afternoon.
The 98 percent figure is worth pausing on. Coverage that high on a frontend is unusual, and it was not the goal in itself. It was the point at which the team could stop asking "what did we not test" before every release.
What changed for the client?
| Area | What moved |
|---|---|
| Release cycles | Faster development iterations and a shorter time to market for new features and updates |
| QA process | QA cycles compressed with little manual intervention, so the team released with more confidence and more often |
| Product quality | Proactive test coverage and stage validation cut post release defects, which showed up as better customer satisfaction and product reliability |
None of these are exotic outcomes. They are what happens when a genomics product is engineered the way good software is engineered anywhere else, with the scientific rigour kept intact underneath.
What does this mean if you are building a variant calling product?
Define the contract between stages before you write the stages. In this engagement that was TypeScript types, but the principle holds in any language. A pipeline whose stages agree on what they pass each other can be changed one stage at a time. A pipeline that passes loose files around cannot.
Treat the application as seriously as the caller. Bioinformatics teams tend to pour rigour into the algorithm and leave the UI to chance. The UI is what your users touch, and a regression there costs you trust just as surely as a bad call does. Test coverage on it is not a luxury.
One honest caveat. Automation of this depth is an investment up front, and it pays back over releases, not on the first one. If your roadmap is a single launch, it is harder to justify. If you plan to ship updates for years, it is the cheapest decision you will make. The same trade off comes up in our regulatory and validation work, where the test evidence is also what goes into the submission. Nextflow pipelines with the same stage discipline are what our GenXFlo accelerator is built to produce.
Questions people ask about this work
What is secondary analysis in NGS?
It is the step between raw sequencing data and the biologist. Sequencing produces raw reads. Secondary analysis aligns those reads to a reference genome, calls the variants where the sample differs from it, annotates them, and produces a report. This platform covered all four stages, from raw sequencing data to a result a researcher can act on.
What did Sequoia build?
A modular mutation calling pipeline covering alignment, variant calling, annotation and reporting, programmatic validation of each stage in TypeScript, the web application for configuring runs and reviewing called variants, and a Cypress test framework covering 98 percent of the frontend workflows, wired into continuous integration.
Why validate pipeline stages with TypeScript?
Each stage's inputs and outputs are declared as types and checked programmatically, so a malformed or unexpected result cannot pass silently into the next stage. It makes the mutation calling logic more reliable and keeps downstream interpretation consistent, and it lets one stage be replaced without retesting the whole chain by hand.
What did 98 percent test coverage change?
It let the team run continuous integration with confidence, catch UI regressions early, and cut manual testing to a small residue. Release cycles got shorter, QA cycles compressed, and post release defects fell. It is the number behind every other outcome on this page.
How big was the team?
Five engineers from Sequoia, covering the pipeline, the web application and test automation. If you are scoping something similar, start a conversation and we will tell you what a first team looks like for your product.
Building a pipeline that has to be right every run?
Tell us the data, the stages and how often you need to ship. We will come back with an approach and a team.
Start a conversation