The engineering behind a genomics company's custom assay design platform
Researchers design custom genotyping assays on this platform. Sequoia is its end to end engineering partner: the design pipelines, the reference databases they draw on, the web application researchers use and the APIs that tie it to the client's wider systems. Time to market for new assay products is up 50 percent and support costs are down 40 percent.
What does the platform do?
A genotyping assay is only as good as its probes. The platform lets a researcher pick the genomic regions they care about, then selects and optimises the probes for the assay, checks the design, and hands off files that manufacturing can build from. It has to be usable by a scientist who is not a bioinformatician.
The range of work that runs through it is wide. A sample:
| Field | What researchers design |
|---|---|
| Genotyping and genetic research | Custom assays for studying genetic variation across populations |
| Cancer research | Assays that pick out mutations and biomarkers tied to specific cancers |
| Plant and animal genomics | Plant and animal genome studies for breeding programmes and trait selection |
| Pharmacogenomics | Assays on how genetic variation shapes drug response |
| Infectious disease | Pathogen detection and host pathogen interaction studies |
Every one of those users expects the design to come back fast and the probes to be right. That is the bar the engineering has to clear, and it is why this sits inside our bioinformatics and genomics practice rather than a generic web team.
What made it hard?
Probe selection is a balancing act. A probe has to be specific enough to hit only its target and sensitive enough to hit it reliably, and on a complex genome those two pull against each other. The pipeline has to make that trade well, at scale, for thousands of targets per design.
The platform also does not live alone. It has to exchange data with the client's other tools and with external bioinformatics platforms, and each of those integrations needs its own customisation. Large studies push high throughput data through the pipeline and expose computational bottlenecks that a small design would never hit. And some researchers need assay customisation that the standard flow was never built for.
Under all of that sits a codebase that had to keep serving customers while its foundations were replaced. There was no option to stop, rewrite and relaunch.
What did Sequoia build?
Sequoia came in as the end to end engineering partner, building the web application and the pipelines across several of the client's assay products. The work falls into three layers.
Design pipelines for genotyping products
New pipelines for new products, and customised pipelines for products already on the market. Each one was integrated with the client's cloud analytics platform for pipeline execution, then tuned for faster turnaround and better probe selection. Pipelines are written in Nextflow, which is the same tooling our GenXFlo accelerator is built around.
Reference databases shared across applications
Two reference stores that the pipelines and other applications all draw on. A reference SNP database generated by an ETL tool we wrote against the JSON files NCBI publishes for dbSNP. And a second reference database converted from flat TSV files into something queryable. Building these once, centrally, is what let each new product pipeline start from a known baseline.
Web application and backend APIs
The Angular web UI is where researchers see products, raise custom design requests, track orders and download generated design files. Behind it, a .NET backend with a layered services architecture exposes two REST APIs. One serves the UI and a number of the client's internal applications. The other runs pipelines in the background and reports status back to the UI as designs progress.
Data lives in SQL Server. Deployments are staged, dev to test to production, and automated through Jenkins CI/CD. Testing is automated.
How was the platform kept current while it stayed live?
Two upgrades, both of the kind teams put off. The backend went from .NET Framework 4.6 to .NET 6. The front end went from AngularJS 1.8 to Angular 10. These are not point releases, they are different frameworks that share a name, and both were done incrementally so the APIs the client's other applications depend on kept working throughout. Compatibility and performance were tracked at each step rather than checked at the end.
Reference data grows and old versions rarely get deleted, so storage cost creeps. We introduced a tiered storage policy that pushes older reference databases to cheaper storage while keeping current data fast. Cost went down without anyone noticing a slower query.
This is the part of platform work that does not make a headline and decides whether the platform is still healthy in five years. It is the same discipline we bring to cloud and data platform engagements generally.
What did the client get out of it?
| Metric | Result |
|---|---|
| Time to market | Improved by 50 percent, through parallel development and close integration with the client's bioinformatics team |
| Support costs | Cut by 40 percent through automated design workflows |
| Customer turnaround | Faster path from design to delivery of custom assay panels for the client's customers |
| Team | Grew from one engineer to a dedicated team of four |
The team growth is the tell. Engagements that start with one engineer and end with a dedicated team do so because the client kept finding more to hand over. That is the shape of a partnership rather than a project.
What does this mean if you run a genomics product platform?
If your customers design products through your software, the platform is part of the product. A slow or brittle design tool costs you launches. The pattern that worked here was to treat pipelines, reference data and the application as one system with one team, rather than three handoffs between three vendors.
Reference databases deserve their own budget line. Build them centrally, version them, and give every pipeline the same baseline. Most of the 50 percent gain in time to market came from not rebuilding the same foundations for each new product.
One honest note. Framework upgrades of this size only go smoothly when the APIs are well covered by automated tests before you start. If yours are not, that is the first piece of work, and it is worth doing before anyone touches a version number.
Questions people ask about this work
What is a custom genotyping assay design platform?
It is the software a genomics company's customers use to design custom genotyping assays. A researcher chooses the genomic targets, the platform selects and optimises probes, and the resulting design files go to manufacturing. It is used across genetic research, cancer, plant and animal genomics, pharmacogenomics and infectious disease.
What did Sequoia build?
The design pipelines for new and existing genotyping products, reference databases built from NCBI dbSNP and from other flat file sources, the Angular web application, and the .NET REST APIs that serve the UI, the client's internal applications and pipeline execution. Sequoia is the end to end engineering partner on the platform.
What results did the engagement deliver?
Time to market for new assay products improved by 50 percent. Support costs fell by 40 percent through automated design workflows. The client's customers get their custom panels faster from design to delivery. The Sequoia team grew from one engineer to a dedicated team of four.
How were the platform upgrades handled?
The backend moved from .NET Framework 4.6 to .NET 6 and the front end from AngularJS 1.8 to Angular 10, incrementally and without breaking the applications that depend on the APIs. A tiered storage policy moved older reference data to cheaper storage to keep cost and performance in balance.
What is the technology stack?
Angular on the front end, .NET 6 on the backend, SQL Server for data, Nextflow pipelines, and staged deployments from dev to test to production automated with Jenkins CI/CD. Testing is automated. If your platform runs on a similar stack, start a conversation and we will tell you where we would begin.
Running a product platform your customers design on?
Tell us the products, the pipelines and where the bottlenecks are. We will come back with an approach and a team.
Start a conversation