← All Systems
LIMS PlatformIn Progress

TraceLab: A Laboratory Information Management System for Research Data Traceability

TraceLab is a laboratory information management system designed to turn sample handling, lab workflows, approvals, and reporting into a traceable system of record.

System designer and full-stack builder · 2025 — ongoing

  • Python
  • FastAPI
  • PostgreSQL
  • SQL
  • Alembic
  • Next.js
  • TypeScript
  • Tailwind CSS
  • Supabase
  • Docker
  • Docker Compose
Role
System designer and full-stack builder
Status
In Progress
Timeline
2025 — ongoing
Type
LIMS Platform
Access
Private · sanitized case study

Context & why it matters

Research labs depend on trustworthy sample records: a result is only as reliable as the chain that links it back to the sample, the work, and the conditions that produced it. When samples, results, inventory, and approvals are scattered across spreadsheets and informal handoffs, that chain breaks and traceability suffers. TraceLab began as a single-lab system and is evolving toward a multi-institution, multi-lab research data platform.

Sample integrity is the backbone of trustworthy lab results — lose the chain and everything downstream is in doubt.

Problem

A sample can pass through several hands and stages before a result is reported, and when those steps live in spreadsheets and informal notes it's hard to know what happened, when, and by whom. Approval workflows need clear ownership; lab managers need visibility without manually reconciling spreadsheets; and cost recovery has to connect services back to the projects and samples that incurred them.

System goals

  • Track the sample lifecycle from intake to reporting
  • Keep every result linked to the work that produced it
  • Support lab roles and access boundaries
  • Give managers visibility into workflow status
  • Preserve auditability for sensitive operations
  • Support future multi-lab and institution-scoped workflows
  • Enable better research data quality and reuse

Architecture

TraceLab uses a Next.js + TypeScript frontend, a Python/FastAPI backend, and a PostgreSQL system of record, structured around a clear separation between the interface, workflow logic, and database layer. The data model is designed around lab-scoped entities such as projects, samples, users, roles, services, invoices, and audit events, so each workflow can be traced without mixing records across contexts.

  • Interface — a Next.js (App Router) + TypeScript front end styled with Tailwind CSS, with server components for data-heavy views
  • Backend — a Python/FastAPI service whose typed API endpoints mediate every state change
  • Database — PostgreSQL (hosted on Supabase) as the system of record, with schema migrations managed by Alembic
  • Access control — role-based, lab-scoped boundaries enforced on the server
  • Audit & logging — an append-only trail of who changed what, and when, for sensitive operations
  • Reporting — dashboard and report views derived only from validated records
  • Packaging — Docker and Docker Compose for reproducible local and deployment environments
  • Files — sample- and result-linked attachments where a workflow needs them
TraceLab architecture — hover to enlarge

Core features

  • Project setup and lab context
  • Sample registration and intake
  • Sample status tracking across the workflow
  • QC and review workflows
  • Dataset and result approval
  • Inventory and equipment awareness
  • Cost-centre and service costing workflow
  • Reporting and dashboard views
  • Audit trail and end-to-end traceability

Technical decisions

Workflow-first data model
I modelled the real lab workflow first — projects, samples, services, results — so the schema mirrors how work actually flows rather than an idealised version of it.
Python/FastAPI backend behind a typed API
The workflow logic lives in a Python/FastAPI service exposed through a typed API, with Alembic managing PostgreSQL migrations — so the data-heavy backend and the Next.js/TypeScript frontend each play to their strengths.
Lab-scoped access boundaries
Records and permissions are scoped to a lab and role, so people see and change only what belongs to their context.
Traceability as a first-class concern
Every state change is captured, so any result can be traced back to the work, conditions, and people behind it.
PostgreSQL-backed system of record
Relational integrity and constraints fit a domain where every record must tie back to a real sample and stage.
Private source, public architecture
The source stays private; the portfolio shares architecture and decisions instead, so the thinking is visible without exposing the system.
Incremental build, not a big-bang rewrite
Building in steps keeps the first single-lab version usable while the multi-lab model takes shape.
Sanitized proof, never private data
Proof is shown as diagrams and dummy-data screenshots, never real lab records.

Tradeoffs

  • Show the architecture, keep the source private

    TradeoffLess to click through publicly, in exchange for protecting an active system and its data.

  • Design a flexible multi-lab model early

    TradeoffMore upfront modelling, so the first single-lab version stays useful while leaving room to scale.

  • Auditability without a heavy interface

    TradeoffLogging happens behind the scenes, so the trail stays complete without cluttering the screens people use.

  • Workflow-specific where it matters, generic where it doesn't

    TradeoffSome bespoke modelling for lab specifics, balanced against reusable, maintainable components elsewhere.

  • Leave seams for future deployment paths

    TradeoffA little extra structure for multi-institution use now, without overengineering the first release.

Outcomes

  • A single, trustworthy timeline for every sample
  • Validation that catches data-entry errors at the point of capture
  • Sensitive operations that stay auditable over time

What it demonstrates

Shows I can model a regulated, audit-heavy domain and turn it into a dependable system of record.

  • Translating real lab workflows into a coherent software architecture
  • Reasoning about traceability, data integrity, roles, and auditability
  • Designing systems that fit real institutional workflows
  • Thinking beyond simple dashboards into data infrastructure

Proof assets

Some proof assets use dummy data or are shared as private walkthroughs to protect sensitive systems and records.

  • The admin control centre — system summary and quick navigation, on dummy data.
    Operational dashboardThe admin control centre — system summary and quick navigation, on dummy data.
  • A role-scoped view surfacing low-stock reagent alerts, on dummy data.
    Lab manager dashboardA role-scoped view surfacing low-stock reagent alerts, on dummy data.
  • Lab billing — invoices, payments, and revenue by service, on dummy data.
    Cost centreLab billing — invoices, payments, and revenue by service, on dummy data.
  • Invoice and payment tracking generated from project costings, on dummy data.
    InvoicesInvoice and payment tracking generated from project costings, on dummy data.
  • A read-only, auto-rotating lab status board.
    Live display kioskA read-only, auto-rotating lab status board.

Privacy

Next steps

  • Add the architecture diagram
  • Add a sample-lifecycle walkthrough
  • Expand the cost-centre and reporting narrative

Stack

  • Python
  • FastAPI
  • PostgreSQL
  • SQL
  • Alembic
  • Next.js
  • TypeScript
  • Tailwind CSS
  • Supabase
  • Docker
  • Docker Compose