QuicLens

The problem

Research labs running RT-QuIC and similar fluorescence assays were stuck analyzing plate data in spreadsheets and one-off scripts; the process was 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 application: researchers upload plate data, review analysis and classification results in the interface, work within organization and lab boundaries, and retain the provenance needed to reproduce and audit the work later.

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.

The application keeps identity, authorization, analysis, and persistence separate. WorkOS establishes identity, the backend resolves organization and lab context, and every tenant-scoped operation is checked before DynamoDB or archived S3 data is accessed. The entire AWS platform is reproducible in CDK.

Infrastructure evolution

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.

Engineering decisions & trade-offs

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

Lab usage is bursty, with heavy activity during analysis runs and little activity 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?

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.

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

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.

Testing & reliability

• 143 named backend pytest functions across 9 test modules covering curve fitting, SD50 math, classification, thresholds, upload validation, parser helpers, assay logic, and API integration. This is the test inventory present in the repository, not a claimed current CI pass count.
• Iterative security hardening: dedicated work addressing auth, role enforcement, and cross-tenant data-integrity issues surfaced by principle-based self-audits.