Overview
What is the Vaccine Adjuvant Compendium (VAC)?
The Vaccine Adjuvant Compendium (VAC) is a federal tool at NIAID's Division of Allergy, Immunology, and Transplantation (DAIT) that helps vaccine researchers find suitable adjuvants (compounds that strengthen a vaccine's immune response) and connects researchers directly with the developers behind them.
My Role
I joined VAC as a junior developer contracted through NTT Data Services, turning my senior's Photoshop mockups into a React frontend. In 2020, I became the main driver of NTT Data's side of the project, taking on cross-browser support, Section 508 compliance, and backend integration with NIAID's internal developer team.
Results
VAC launched in 2020, during active COVID-19 vaccine development, and it's still in use today. It's helped researchers build real vaccine candidates — including for COVID-19 and typhoid — and other organizations now add their own data to it, so it keeps getting more useful over time.
VAC is recognized alongside established databases like Vaxjo as a go-to resource for adjuvant data and recent research has even used VAC's records to train AI tools for identifying adjuvants in scientific literature.
The Problem
A Missing Federal Resource
Before VAC, researchers didn’t have a centralized source to find the right adjuvants for vaccine development from federal research. Broader academic databases existed, but nothing focused specifically on NIH-funded adjuvant research, there was no standard way to track the same adjuvant across sources, and they had no built-in path to the people who actually made it.
In 2018, NIAID's Blue Ribbon Panel recommended something that didn't exist yet: a public database of NIAID-funded adjuvants, with a real way to reach out and request access.
When COVID-19 came to the US in 2020, researchers needed to connect with adjuvant developers, fast.
What Researchers Needed
A centralized, searchable database of NIAID-funded adjuvants, filterable by keyword, receptor, immune profile, disease area, and product grade
A standardized way to track each adjuvant, so the same compound isn't described differently across sources
Direct contact information for the researcher or institution behind each adjuvant
An easy way to export and share what they found — a PDF they could save, print, or share
Searching the Database
A Missing Federal Resource
I built the search interface using Material-UI components that hooked up to the NIH developers' backend database. Researchers can filter by keyword, receptor of interest, immune profile, disease area or pathogen, and product grade.
Every entry lists direct contact information for the IP holder, along with the adjuvant's properties (chemical nature, receptor, mechanism of action, storage and stability), its preclinical and clinical use with associated publications, and its product grade and formulation.
Every adjuvant also gets a Vaccine Ontology ID, linked to a corresponding entry in Ontobee (a standardized identifier researchers are encouraged to cite in their own publications), so the same compound is tracked consistently across the literature.
Filtering adjuvants and finding IP holder contact information
Solving the PDF Export Problem
Browser to PDF Challenges
VAC needed to export forms as PDFs, but the styling kept breaking in translation. Our layouts were built on percentages and media queries — great in a browser window, useless in a PDF, which has no browser window for a percentage to reference.
I realized that the fix could be simpler than the styling libraries we'd been leaning on: since a PDF has a fixed width, the columns could just use fixed widths too. No percentages, no media queries needed.
We were able to delete several styling libraries from our base template. It felt backwards, given that I spent most of my time working in the government making fixed layouts responsive. Most of my team's NIH projects required PDF exporting, so my browser to PDF conversion fix became part of the base template we used on every project.
Exporting adjuvant listings to PDF
Version Control: Azure vs Git
Learning a New System on the Fly
This was my first project working directly with NIH developers, and my first time using Azure DevOps Server (TFS) (I'd only ever used Git). The team's setup didn't use feature branches, so I was working in the same files as 16 other developers at once and code got tangled regularly. I already used VS Code as my daily code editor, but I had to quickly learn Azure's backend to keep up with the regular deployments.
I still prefer Git, but I'm glad I learned it. I went from a junior developer routed through my supervisor to being my company’s main driver making direct daily calls with NIAID's team, and partnering with them to solve the bugs they get stuck on.
Wrap Up
Working for NIAID/NIH during the COVID-19 pandemic was extremely chaotic. Case numbers around the world were exploding, and my team at NTT Data Services had people spread across different agencies and projects, all rushing to build tools and websites to support researchers trying to find a cure or a vaccine. It was so rushed that during the shutdown, we even handed off badged equipment through covert drops in parking lots, just to keep our access consistent through months of lockdown.
Things moved so fast that we resorted to safely dropping off laptops in parking lots, just to keep our access consistent through months of lockdown. It's nostalgic now, remembering waving across the parking lot in Bethesda to my teammates.
My team of six was stretched thin, which gave me the opportunity to step into a major role for the first time. I went from an assistant on projects to a fully independent developer, driving our side of the work with NIAID's team directly. The pace was relentless for months, but VAC is the most impactful and rewarding project I've released, and I'm extremely proud of it.