Our work

Systems we have built, and the problems they solved.

Each engagement starts with a real problem in a study team’s day. Here is what we built, what was getting in the way, and what changed.

Clinical trial software

Clinical trial data management platform

What it does

A browser-based platform for clinical study teams to move, process and track study data. Configurable pipelines ingest from any source (CRO extracts, lab feeds, EDC exports) and route data through processing steps without anyone writing a script. Orchestration triggers jobs, manages file transfer tasks, sends notifications on every state (info, warning, error), and records a complete audit history of each task, configuration change and data movement. Existing SAS and R code plugs directly into the pipeline, so prior investment in edit checks, safety outputs and analysis datasets keeps working.

Problem solved

  • Every new data source needed custom scripting, so study teams waited days or weeks to see their own data
  • Manual file movement left no reliable audit trail, which becomes a problem at inspection
  • Programmers spent their time on data plumbing instead of analysis
  • No single view of what ran, when, by whom, or whether it succeeded
  • Folder and permission provisioning handled by hand, study by study

What changed

  • Time to first file import drops from days of scripting to minutes of configuration
  • New sources onboarded without programming
  • Every action audited automatically, with no separate documentation effort
  • Repeatable pipelines remove the rework between studies
  • Study teams self-serve instead of queuing behind IT
Research computing

Multi-language research computing studio

What it does

A browser-based studio where researchers write and run SAS, Python, R and SQL from one interface against shared compute, with no local installs and no per-machine setup.

Problem solved

Environment drift between analysts. Code that runs on one machine and not another. Analysts blocked waiting on IT for installs. Cross-language work split across disconnected tools.

What changed

Analysts are productive on day one instead of after a setup cycle. There is one environment to maintain instead of many, and cross-language work happens in one place.

For a top global pharmaceutical company

Role-based provisioning automation

What it does

Command-line tooling that reads role-based security definitions and provisions folder structures and permissions across a large research estate.

Problem solved

Manual provisioning was slow, inconsistent and error-prone. Access mistakes carry compliance consequences. Onboarding a study or a user meant a ticket and a wait.

What changed

Provisioning runs as one command instead of a manual checklist. Permissions match policy by construction, and structure stays consistent across every study.

Python · Observability

Redshift usage monitoring dashboard

What it does

A Python service for a pharma client that polls Amazon Redshift for live connections and query state (running, blocked, completed, failed), turns it into charts, and emails an admin dashboard on a schedule, no login required.

Problem solved

Cluster health was only visible by hand-querying system tables. Blocked queries and connection saturation went unnoticed until study teams complained, with no historical view of usage.

What changed

Admins get proactive visibility in their inbox instead of a portal to check. Issues surface before they affect study teams, and usage trends now inform capacity planning.

React Native · Field sales

Field sales mobile app

What it does

A React Native app that gives on-site sales representatives secure, offline-first access to the patient and visit information they need in the field, syncing back once connected.

Problem solved

Reps relied on printouts, memory or a spotty connection to look up information on site, with no reliable way to capture visit data while offline.

What changed

Reps work the same way with or without a signal, and data captured in the field lands back in the system automatically instead of via manual re-entry.

SAS · Cloud storage

Provider-agnostic SAS storage macros

What it does

A SAS macro library exposing one create/read/update/delete interface for cloud object storage, with adapters underneath for AWS S3, Azure Blob and Google Cloud Storage.

Problem solved

Programs were hardwired to one vendor’s storage API. Multi-cloud or cloud-migration work meant rewriting SAS code, and programmers needed vendor-specific knowledge to touch it.

What changed

Programmers write to one macro interface regardless of provider. Moving between clouds, or running on more than one, needs no changes to study programs.

CDISC SDTM · Clinical data standards

SDTM mapping tool

What it does

A tool that maps collected clinical data into CDISC SDTM domains, applying controlled terminology and structural rules on the way to submission-ready datasets.

Problem solved

SDTM mapping was done with one-off scripts per study, so terminology and structure were applied inconsistently and submission prep was slow and error-prone.

What changed

Mapping is consistent and repeatable across studies, with less bespoke programming per study and a faster path to submission-ready output.

Python · Reusable component

Data ingestion pipeline module

What it does

A reusable ingestion module that parses, validates and lands files from CRO extracts, lab feeds and EDC exports into a common shape before downstream processing, shared across pipelines rather than built per study.

Problem solved

Every new source format meant one-off parsing code. Validation and error handling were duplicated, and inconsistent, across pipelines, so failures were hard to trace.

What changed

New source formats are added by configuration, not new code, and validation and error handling behave the same way everywhere the module is used.

Ansible · Terraform · Apptainer

Infrastructure automation for research computing

What it does

Infrastructure-as-code and configuration management with Terraform and Ansible, plus Apptainer containers for portable, reproducible compute environments on shared and HPC-style research infrastructure.

Problem solved

Environments were built by hand and drifted between servers. Root-requiring containers were not viable on shared research infrastructure, and infrastructure changes were untracked and hard to reproduce or audit.

What changed

Environments are defined as code, version-controlled and reproducible. Apptainer containers run without root, so they fit HPC and shared research computing policy, and infrastructure changes are reviewable like any other code change.

React · R package validation

R package risk-scoring dashboard

What it does

A React front end presenting automated risk and quality scores, maintenance activity, test coverage, community adoption, for R packages under evaluation for use in a validated environment.

Problem solved

Deciding whether a package was safe to use was a manual, ad hoc review, with criteria applied inconsistently across teams and no lasting record of why a package was approved.

What changed

One place shows a package’s risk profile before adoption, giving teams a consistent, defensible basis for approval and an auditable record of what was evaluated.

Have a similar problem to solve?

Talk to us