Skip to content
tren
№ 002
live

FLY AI

Aviation procurement from inbound email to delivery; LLM-parsed RFQs, nightly bid matching, operations on one screen.

Ownership
Company · team · AI PORT
Role
Technical lead — architecture, LLM pipelines, backend, DevOps
Team
4 developers · 14 months
Period
Nov 2024
Open link
Live ↗
https://flyai.tr№ 002
FLY AI — web
FLY AI — mobile

Context

In aviation parts procurement an order begins as an RFQ email to a supplier and continues through quote, proforma invoice, purchase order, payment, logistics and customs. At most companies that chain is split between email, Excel and part-query systems such as ILS. FLY AI folds the chain into one operations screen and automates its two most expensive steps: structuring the inbound request and matching the quotes.

Constraints

  • Requests arrive as unstructured attachments (PDF, Excel, free text); model output must bind reliably to business rules.
  • Several currencies inside one order; different permission tiers for purchasing, finance and logistics (JWT + 2FA).
  • Customers work with OEMs such as Collins Aerospace, Honeywell and Safran; enterprise security and auditability are not negotiable.

Architecture

From email to screen: parse → query → store → match at night → present in the wizard.Inbound email + attachmentsLLM parsing (Python)ILS part querySpring Boot API · MongoDBNightly bid matchingNext.js — transaction wizards
From email to screen: parse → query → store → match at night → present in the wizard.

The LLM parsing pipeline is Python; the frontend is Next.js (shadcn/ui, TanStack Query); the backend runs REST APIs on Java 17 / Spring Boot 3 with MongoDB for high-volume corporate records. Dev / QA / Prod environments are isolated with Docker behind an Nginx reverse proxy; every merge reaches QA through Git CI/CD.

§ Decision log

DecisionAlternativeWhy
01RFQs are pulled from email automatically; attachments are structured by an LLMThe operations team keys RFQs in by handIn aviation, requests arrive as emails with PDF/Excel attachments; letting the model parse the unstructured attachment removed data entry and made programmatic ILS part queries possible.
02Bid matching runs in a nightly background pipelineSynchronous computation when the user opens the screenMulti-source supplier quotes accumulate over hours; batch evaluation at night cut cost and let the screen open in the morning with a ready match.
03The whole trade flow on one screen, driven by transaction wizards (RFQ · Quote · PI · PO · freight)A separate module and list per stepOperations must see where an order is stuck without touring three screens; the wizard bakes each step's required data into the UI.
04Java 17 / Spring Boot 3 backend + MongoDB, Next.js frontendA single Node.js monolithA typed, mature backend for corporate record volume and long-lived business rules; a document schema fit the variable structure of RFQ attachments.
05Separate Dev / QA / Prod Docker environments, Nginx reverse proxy, Git CI/CDManual deploys to a single serverWith four developers every merge had to be verifiable in QA; without environment parity the nightly pipelines could not be tested.

§ Outcome

−60%
Quote preparation time (aiport.tr)
+30%
Sprint throughput (AI-assisted migrations)
40+
Domain modules refactored
4 people · 14 months
Team · duration

§ Retrospective

What I would do differently today

TODO: What would you do differently today? (e.g. bind the LLM parsing output to a schema earlier, make the nightly pipeline event-driven, set up observability from day one…)