SAFAPAC

Summary

SAFAPAC is an internal techno-economic-analysis platform for Sustainable Aviation Fuel research. I took substantial ownership of the FastAPI/PostgreSQL backend and AWS delivery, helping evolve an incomplete local application into an AWS-hosted internal pilot supporting 6 TEA researchers and 5 Airbus staff.

Starting problem

The starting point was an incomplete local application supporting a specialist calculation workflow. The methodology was still evolving, selector-dependent defaults were large, and the team needed a repeatable way to deliver the assigned application scope to AWS. The engineering problem was therefore both a backend/data problem and a release-reliability problem, not a claim of sole product ownership.

Role and approach

I took substantial ownership of the FastAPI/PostgreSQL backend, database, calculation integration, Superadmin APIs, and AWS/DevOps delivery. I worked with domain specialists and a frontend developer to make the assigned workflow easier to validate, hand over, and operate. The frontend remained the frontend developer’s responsibility, and the Sustainable Aviation Fuel methodology remained the domain specialists’ responsibility.

Engineering decisions

The following decisions kept the backend, data boundary, and release path understandable and proportionate to an AWS-hosted internal pilot.

Turning methodology into executable contracts

I worked with LCA/carbon specialists on expectations around total CO2 emissions, carbon intensity, and carbon-conversion efficiency. I also worked with TEA/business specialists on cash flow, NPV, IRR, and payback. Their input and output expectations became independent regression contracts so the checks did not simply treat current application output as the oracle.

A boundary deliberately not automated

Newer methodology material included process/reference data that was not yet incorporated into the approved default workbook and application mapping. I retained the approved v1.1 dataset rather than inventing process-feedstock-country relationships. The Superadmin direction leaves future values to be added explicitly by domain experts when those relationships are approved, instead of silently deriving or publishing unsupported defaults.

Default governance

The governed default set contains 33,047 governed defaults across 12 processes, 22 feedstocks, and 217 countries. The backend supports draft, publish, and rollback workflows, and the approved backend handoff to the frontend developer keeps default governance separate from the client-side presentation.

Sensitivity redesign

I redesigned the 33-point sensitivity workflow to replace 33 full calculation-engine executions with reusable prepared inputs and targeted NPV projections. The verified result is 50 ms p95 across 10 staging acceptance cycles. This reports the accepted workflow result without adding a comparison baseline.

TLS reliability

An expired TLS certificate disrupted expert access during deployment. I restored HTTPS and automated certificate renewal so renewal now occurs automatically rather than depending on manual intervention after an expiry.

Deployment safety and cost control

Terraform-managed staging validates application releases, infrastructure changes, and rollback behavior before the internal pilot receives a change. Because staging is primarily needed around release work, I implemented a six-hour automatic staging shutdown to reduce the risk of forgotten temporary resources generating unnecessary AWS cost.

AWS delivery

The delivery boundary uses Terraform, a VPC, EC2, private RDS, S3/CloudFront, Cognito, Docker, Nginx, GitHub Actions, OIDC, and SSM. Terraform keeps the infrastructure repeatable and helps reduce configuration drift; private RDS keeps application data behind the delivery boundary; S3/CloudFront serves the web layer; Cognito covers authentication; Docker packages the application; Nginx handles the HTTPS edge; and GitHub Actions provides OIDC authentication with SSM-based deployment execution for a short-lived, repeatable release path.

The approved operating-cost fact is $51.27/month average from March–August 2026 across 20 billed AWS services. It is presented as the internal pilot’s recorded infrastructure cost, not as a general cost promise for another deployment.

Current state

Current status — September 2026: SAFAPAC is an AWS-hosted internal pilot. The core Superadmin backend APIs are complete and meeting-approved, the frontend handoff is complete and frontend implementation is in progress, and remaining backend work is limited to cleanup/refactoring plus direct active-default CRUD.

Limitations

This public case study does not publish proprietary formulas, expected numeric fixtures, raw expert documents, internal identifiers, secrets, internal user data, client-sensitive configuration, or copied professional artifacts. It does not claim frontend ownership, SAF methodology authorship, whole-product sole ownership, broad adoption, or unsupported production maturity. The public narrative stays at the approved AWS-hosted internal-pilot boundary.