Dillon Green
ALL WORK

CASE STUDY Internal tool · sole developer

PAR: parts, orders and repairs for a flight simulator fleet

PAR is the system an airline's 40-person flight simulator maintenance department uses every day to track parts, order them, repair the simulators they belong to and account for the money. I designed it, built it and run it, working with AI coding agents under my review.

Codebase
~72klines, one developer
Surface
231routes · 3 roles
Schema
~56SQLite tables + audit ledger
Tests
340+automated checks
Users
40people, in daily use
Fleet
26simulator devices, two sites
Migration
15importers from legacy systems
Schematics
6,000+drawings converted to SVG

01

Problem

A full flight simulator is an aircraft cockpit plus racks of computers, I/O and motion hardware, and it has to pass regulatory qualification to stay in service. Keeping two dozen of them in that state means always knowing which part is where, what condition it's in, what's on order and which budget is paying for it.

The department's records were split between a legacy MS Access database and GigaTrak, and the two had drifted apart. Part conditions, the work to fix them, purchasing and budgets weren't connected in one place. The schematics that show where a part sits in a simulator were MicroStation CAD drawings, which needed CAD software to open and weren't linked to stock.

The department needed one system of record that technicians would actually use on the floor, and a migration that didn't lose history.

02

What I built

  • Inventory that matches the hangar

    Consumable, rotable and repairable parts, serial tracking, and a building → location → bin hierarchy.

  • Requisition to shelf

    Requisitions become purchase orders, and receiving an order puts the parts straight into inventory.

  • Work orders that open themselves

    When a part's condition changes, PAR opens the work order to repair it, so nothing broken gets lost on a shelf.

  • Budgets and project accounting

    Spending is tracked against budgets and projects in the same system as the parts and orders.

  • Fleet-level reorder logic

    Spares are aggregated across 26 simulator devices at two sites, with critical and low-stock tiers and ABC/FSN classification.

  • Schematics linked to stock

    6,000+ CAE MicroStation DGN drawings converted to SVG through GDAL, with part numbers on the drawing linked to live stock.

  • A migration that keeps history

    15 importers off MS Access and GigaTrak, including a reviewable two-way, field-level reconcile engine that learns vocabulary mappings by majority vote, and an idempotent history import that keeps original timestamps.

  • Integrations on the floor

    A REST API for the discrepancy system, QR labels in Zebra ZPL through a network print agent, and photo capture from phones.

03

Architecture

PAR is deliberately boring to operate. It's one Python process: Flask behind Waitress, server-rendered Jinja templates with Bootstrap, and SQLite in WAL mode. PyInstaller packages it as a single-file Windows service, so a deploy is one file and a service restart.

For a department of this size, a single-file database with WAL gives concurrent reads and very simple backups. A 30-thread concurrency test keeps that assumption honest. Three roles control what each person can change, and an immutable audit ledger records every change.

PAR architecture Browsers, phones and the discrepancy system's REST client call a Flask application served by Waitress, which stores data in SQLite. The app runs as a one-file Windows service. Importers bring in data from MS Access, GigaTrak and CAE documentation. A schematics pipeline converts DGN drawings to SVG with GDAL. The app sends labels to a network print agent, and the database is backed up daily and offsite. CLIENTS · FLOOR DATA IN · OUT solid: requests, data in dashed: output leaving WINDOWS SERVICE · ONE FILE Desktop browsers Jinja + Bootstrap pages Phones on the floor photo capture · QR Discrepancy system REST API consumer Waitress · Flask 231 routes · 3 roles server-rendered Jinja REST API · print jobs SQLite (WAL) ~56 tables immutable audit ledger scrubbed copies for dev Print agent ZPL QR labels → Zebra 15 importers Access · GigaTrak · CAE docs Schematics pipeline DGN → GDAL → SVG Backups daily + offsite PAR architecture: clients call a Flask app on Waitress backed by SQLite, fed by importers and a schematics pipeline, with a print agent and backups. CLIENTS Browsers Jinja pages Phones photos · QR Discrepancy REST API Waitress · Flask 231 routes · 3 roles server-rendered Jinja REST API · print jobs SQLite (WAL) ~56 tables immutable audit ledger scrubbed copies for dev WINDOWS SERVICE · ONE FILE DATA IN 15 importers Access·GigaTrak Schematics DGN→GDAL→SVG DATA OUT Print agent ZPL → Zebra Backups daily + offsite solid: requests and data coming in dashed: output leaving the service
Simplified. Names of internal systems, sites and suppliers are left out on purpose.

04

Engineering practices

PAR was built with AI coding agents working in parallel under my direction. That only works with a test suite that catches regressions before people on the floor do, so 340+ automated checks gate every change.

70
Regression suites

Run in parallel, each against its own copy of the database.

138
Browser end-to-end checks

Headless Chrome, driven by a Chrome DevTools Protocol client I wrote by hand.

30
Threads, one test

A concurrency test that hammers the app and SQLite at once.

The quality gate ratchets: the bar can go up, never down. Backups run daily and offsite. AI-assisted development uses scrubbed database copies, so agents never see real records.

05

Results

Rolled out to the whole 40-person department and in daily use. Inventory, purchasing, work orders, budgets and schematics now live in one system instead of several that disagreed.

The legacy MS Access and GigaTrak data came across through imports a person could review, field by field, without losing the original history or timestamps.

Technicians can open a simulator drawing in the browser, click a part number and see what's on the shelf. Reorder decisions are made across all 26 devices at both sites instead of one device at a time.

Internal tool — details generalized; no proprietary data shown.