Hydar HafizBackend · Cloud · Applied AI

← Back to Featured work

Primary professional case study

SAFAPAC

Deployed beta / internal validation

Rebuilding FastAPI/PostgreSQL backend and calculation workflows while owning Terraform-managed AWS staging/production delivery and containerized CI/CD.

Role
Backend Software Developer (Contract)
Context
Aerospace Malaysia Innovation Centre in collaboration with Airbus
Period
November 2025 – October 2026

Summary

SAFAPAC is a deployed beta/internal-validation sustainable aviation fuel analysis platform developed by the Aerospace Malaysia Innovation Centre in collaboration with Airbus. Hydar’s contribution was to take over an early boilerplate implementation and substantially rebuild and productionize the assigned backend, database, calculation-traceability, validation, and AWS delivery scope.

Context

The platform supports techno-economic analysis workflows for sustainable aviation fuel pathways. It combines researcher-facing calculation workflows with a web application and cloud delivery surface. Hydar worked with five TEA-SAF domain researchers and one frontend developer. A separate five-person Airbus internal pilot group provides the approved validation context for the beta.

Problem

The inherited application needed a stronger foundation for traceable calculations, defensible input and output handling, repeatable validation, and dependable delivery. The engineering challenge was not to claim a new product built alone, but to make the assigned backend and operational scope more coherent and easier for domain and frontend collaborators to work with.

Role and approach

01 · Transformation

What I rebuilt at SAFAPAC

Hydar's assigned engineering scope moved SAFAPAC from inherited code toward a deployable beta under internal validation.
Read this visual as text

A three-part transformation map shows Hydar's assigned SAFAPAC work between inherited early boilerplate code and a delivered beta with internal validation. The dominant center scope covers backend and PostgreSQL, traceable calculations, container delivery, and AWS operations; domain, frontend, and Airbus groups appear as context.

  1. Hydar inherited early-boilerplate SAFAPAC code.
  2. His scope covered backend and PostgreSQL, traceable calculations, container delivery, and AWS operations.
  3. The work moved SAFAPAC toward a deployable beta with internal validation; domain, frontend, and Airbus groups are context.

Hydar owned the assigned backend, database, and AWS delivery work. He restructured the FastAPI/PostgreSQL schema and calculation workflows, strengthened formula traceability and validation, and improved testability and documentation around the parts he maintained. He also automated Terraform-managed staging and production infrastructure using Docker, GHCR, and GitHub Actions, with OIDC authentication to AWS and SSM-based deployment execution across the approved AWS service categories, Linux, Nginx, and HTTPS.

Engineering decisions

02 · Delivery

How SAFAPAC gets delivered

High-level web-to-data delivery within Hydar's SAFAPAC backend, database, and AWS scope.
Read this visual as text

A compact SAFAPAC delivery path connects a web app through HTTPS and Nginx to a FastAPI backend and PostgreSQL. Docker, CI, AWS, and authentication form a supporting platform layer, with beta delivery as the outcome.

  1. The web app connects through HTTPS and Nginx to FastAPI.
  2. FastAPI reads and writes PostgreSQL data.
  3. Docker, CI, AWS, and authentication support the delivery path as a platform layer.
  • Keep calculation behavior behind a clear service boundary so callers can use a consistent workflow and trace without duplicating formula logic.
  • Treat validation and provenance as part of the calculation contract, not as an afterthought in the interface.
  • Separate database/default resolution from the calculation boundary so the assigned workflows remain easier to test and document.
  • Use Terraform and repeatable container/CI delivery paths to keep staging and production reproducible and reduce configuration drift.
  • Use GitHub OIDC authentication instead of long-lived AWS credentials, with SSM providing the deployment-execution boundary.

Collaboration and boundaries

The work crossed backend, data, domain, frontend, and delivery concerns, but Hydar’s public ownership claim is limited to his assigned scope. Domain researchers supplied the TEA context and validation collaboration; the frontend developer owned the corresponding client-side work. The Airbus pilot group is validation context, not a claim of broad public rollout.

Outcome

The assigned SAFAPAC scope was substantially rebuilt and productionized for a deployed beta/internal-validation context. The public-safe outcome is improved calculation traceability, validation, testability, documentation, and release reliability within Hydar’s contribution boundary.

Limitations

This case study does not publish proprietary formulas, default data, internal architecture detail, exact rollout size or geography, customer data, costs, or unapproved performance measurements. It does not claim that Hydar built the whole product alone or that the beta represents general production maturity.