A multi-tenant, cloud-native analytics platform for research labs - engineered and deployed as the sole developer, from data model and authorization rules to React interface and AWS infrastructure.
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.
A serverless, single-region AWS stack defined entirely in infrastructure-as-code.
Frontend - React + TypeScript (Vite) with hand-built SVG charts for the fluorescence-kinetics and dose-response visualizations, 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 tables and GSIs store organization, lab, project, plate, membership, and audit data; an encrypted, versioned S3 bucket retains archived plate records.
Auth - WorkOS AuthKit verifies identity. The backend resolves the active organization/lab and enforces membership, role, and resource-level authorization before tenant-scoped operations execute.
Infrastructure - AWS CDK (TypeScript). The entire stack - buckets, distribution, Lambda, API Gateway, IAM policies, and frontend deployment - is reproducible from code.
QuicLens did not start on its current AWS platform. The first hosted version used Vercel for the React frontend and Railway for the FastAPI backend. I later re-platformed the application onto AWS: the frontend moved to a private S3 origin behind CloudFront, while the API moved to a container-image Lambda behind API Gateway, with the platform defined in AWS CDK v2.
The migration removed the Vercel/Railway deployment dependency while preserving the application model and making the current infrastructure reproducible in code.
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).
The workload is dominated by known, key-based access patterns across organizations, labs, projects, plates, and results. DynamoDB provides predictable performance, on-demand scaling, GSIs for targeted lookups, and point-in-time recovery. Tenant authorization is enforced in the application layer rather than delegated to IAM or a partition key.
The analysis stack (pandas/NumPy/SciPy) exceeds the zipped-Lambda size limits and is far simpler to manage as a container.
Identity and authorization are deliberately separated. WorkOS verifies the user; application-owned organization and lab memberships establish tenant context; role checks and resource-level access rules govern reads and writes, including cross-lab sharing. The development history also includes explicit hardening of auth and cross-tenant data paths surfaced during self-audits.
| Layer | Tech |
|---|---|
| Frontend | React, TypeScript, Vite, Tailwind, custom SVG charts |
| Backend | Python, FastAPI, Mangum |
| Data | DynamoDB, S3 (encrypted) |
| Analysis | pandas, NumPy, SciPy |
| Reporting | ReportLab + matplotlib (server-side PDF) |
| Auth | WorkOS (enterprise SSO) |
| Cloud | AWS Lambda, API Gateway, CloudFront, IAM |
| IaC | AWS CDK (TypeScript) |