BIOMEX Genomics Analytics Platform

How can researchers run complex genomic analysis without depending on manual engineering support?

Role: Project Lead (Development Director)
Timeline: Sep–Dec 2025
Category: Analytics Platform & Team Leadership
Stakeholder: Dalhousie University faculty researcher

Cross-functional team led: 10Cross-functional team ledDirectors, senior and junior developers delivering to a faculty client.
Samples per run (target capacity): 60–90KSamples per run (target capacity)Architecture designed for real-world omics datasets of this scale.
Analysis pipeline delivered: DESeq2Analysis pipeline deliveredEnd-to-end proof of concept: MA plot, volcano plot, and heatmap outputs, verified against expected results.

React
Firebase
R
R Plumber
DESeq2

In 30 seconds

I led a 10-person cross-functional team rebuilding a legacy desktop bioinformatics workflow into a self-service web platform for a Dalhousie faculty researcher, delivering a working DESeq2 differential-expression pipeline as a validated proof of concept.

Cross-functional team led: 10Cross-functional team led
Samples per run (target capacity): 60–90KSamples per run (target capacity)
Analysis pipeline delivered: DESeq2Analysis pipeline delivered

Context

BIOMEX began as a legacy PyQt5 desktop application: powerful, but locked to one machine and dependent on manual engineering support to run analyses. A Dalhousie faculty researcher wanted it rebuilt as a self-service web platform so researchers could run genomic analyses themselves.

The semester’s goal, agreed with the client, was pragmatic: prove the approach works end to end by getting one complete analysis method running accurately in the new architecture, while building the frontend and documentation that future teams would extend.

This is a real team project with a real stakeholder. I led a 10-person team as Project Lead; the honest status is a validated proof of concept, not a finished product.

Data

Source: Researcher-supplied omics data: a raw counts matrix plus a sample metadata file (CSV)
Time period: Per-analysis uploads (no fixed dataset)
Records: Designed for real-world datasets of roughly 60,000–90,000+ samples per run
Granularity: Counts matrix (samples × genes) paired with per-sample metadata

Data quality & handling

File compatibility is verified in two stages: a fast client-side dimensional check (metadata rows vs counts columns), then a server-side value-level match of sample identifiers.
Large files are validated server-side to avoid overwhelming the browser.
The DESeq2 pipeline’s outputs were verified against expected results before acceptance.

Data dictionary

Table	Description	Size
counts matrix	Gene expression counts; samples as columns, genes as rows.	input
metadata	Per-sample attributes (condition, reference level).	input
DESeq2 outputs	MA plot, volcano plot, and heatmap.	output

Analytical approach

The React frontend (hosted on Firebase) posts CSV contents to an R Plumber API on a faculty VM; the API runs DESeq2.R, then returns the generated plots as base64 images the app renders directly.

Upload counts + metadata
Validate & match samples
POST to R Plumber API
Run DESeq2 (R)
Encode plots (base64)
Render results in React

Validation

Verified against expected outputs
The DESeq2 proof of concept produced MA, volcano, and heatmap outputs checked against the expected results from the reference implementation.
Client acceptance
The faculty stakeholder confirmed the proof of concept and the project’s viability for continued development.
Isolated execution
Each request reconstructs CSVs in an isolated server folder so concurrent users cannot overwrite each other’s data.

Limitations

A one-semester proof of concept: frontend ~80% complete, backend ~10%, with one analysis method (DESeq2) fully working.
The backend ran on a faculty VM exposed via ngrok for development — not production-hardened hosting.
Additional methods (edgeR, limma), preprocessing, and single-cell analysis were scoped for future teams, not delivered.

My contribution

Owned: translating faculty requirements into sprint priorities and the overall application architecture.
Owned: coordinating delivery across frontend, backend, and bioinformatics contributors, keeping milestones on schedule.
Team: nine other developers built individual components; the client supplied domain expertise and the legacy PyQt5 reference implementation.
Inherited: DESeq2 statistical logic came from the Bioconductor ecosystem, not written from scratch.

Technical appendix

Architecture

React frontend on Firebase → R Plumber API (POST /run_deseq2, port 8000) on the Faculty of Computer Science VM → DESeq2.R. Plots are saved as PNGs, base64-encoded, and returned as JSON for the React app to render.

Delivery status & handoff

Frontend ~80% complete; backend ~10% (one working method). The closing document hands future teams a prioritized roadmap: complete the preprocessing pipeline (the blocking dependency), then add edgeR/limma, harden hosting (replace ngrok), and lock down CORS.

What I owned vs the team

I owned requirements translation into sprint priorities, the application architecture, and delivery coordination. Nine other developers built individual components; the client supplied domain expertise and the legacy reference; the DESeq2 statistical logic came from the Bioconductor ecosystem.