QuicLens

A multi-tenant, cloud-native analytics platform for research labs — designed, built, and deployed solo, from database schema to React interface to AWS infrastructure.

The problem

Research labs running RT-QuIC and similar fluorescence assays were stuck analyzing plate data in spreadsheets and one-off scripts — slow, error-prone, and impossible to audit. Regulated science needs reproducible analysis, clear provenance, and multiple labs/teams working in isolation without stepping on each other's data.

QuicLens turns that workflow into a real platform: upload plate data, get real-time kinetic analysis and classification, and keep a full audit trail — with strict separation between organizations and labs.

What it does

• Real-time assay analysis — ThT fluorescence kinetics, curve fitting, SD50/dose-response math, and per-sample classification (pandas / NumPy / SciPy).
• Plate-map workflow — design-first plate creation, lifecycle states (Planned → Analyzing → Analyzed → Archived), and plate-level access control.
• Multi-tenancy — organizations contain labs; data is isolated per tenant, with role-based sharing and invites across teams.
• Result reporting — server-generated PDF reports (ReportLab + matplotlib) summarizing assay results, with a research-use disclaimer and signature blocks.
• Audit & governance — action logging across plates and projects, plus a platform-admin console for operators.

Architecture

A serverless, single-region AWS stack defined entirely in infrastructure-as-code.

Frontend — React + TypeScript (Vite), Plotly for data-viz, served as a static build from S3 behind CloudFront with Origin Access Control and HTTPS redirect.

Backend — FastAPI (Python) packaged as a container image and run on AWS Lambda via Mangum, fronted by API Gateway. Clean layered structure: api/routes → services → models, with a dedicated analysis layer.

Data — DynamoDB with per-tenant partitioning and GSIs; an encrypted S3 bucket (retain-on-delete) for archived plate data.

Auth — WorkOS AuthKit for enterprise SSO and multi-tenant identity.

Infrastructure — AWS CDK (TypeScript). The entire stack — buckets, distribution, Lambda, API Gateway, IAM policies, and frontend deployment — is reproducible from code.

Engineering decisions & trade-offs

Why serverless (Lambda + API Gateway) over a long-running server?

Lab usage is bursty — heavy during analysis runs, idle otherwise. Serverless means no idle cost and no servers to patch, and the FastAPI app stays portable (it runs identically locally and in Lambda via Mangum).

Why DynamoDB over a relational database?

Access patterns are tenant-scoped and key-based (org → lab → project → plate → results). DynamoDB gives predictable performance and clean per-tenant isolation via key design, with IAM policies scoped to specific table ARNs as a second layer of tenant safety.

Why a container image for the Lambda?

The analysis stack (pandas/NumPy/SciPy) exceeds the zipped-Lambda size limits and is far simpler to manage as a container.

Tenant isolation as a first-class concern

Isolation is enforced at multiple layers: key design in DynamoDB, service-layer authorization checks, and scoped IAM. The development history reflects deliberate security hardening passes — fixing auth-bypass and cross-tenant data paths found in self-audits.

Testing & reliability

• Backend test suite (~1,800 LOC) covering the analysis math (curve fitting, SD50, classification, thresholds), upload validation, and API integration.
• Iterative security hardening: dedicated work addressing auth, role enforcement, and cross-tenant data-integrity issues surfaced by principle-based self-audits.

Stack at a glance