Boxette Flights

Kunden fragten immer wieder, wo ihr Paket sei und wann sein Flug lande. Die Flugplanseite war eine einzige statische Datei, gespeist von offenen n8n-Webhooks, das Team pflegte die Flugdaten von Hand in einer Google-Tabelle, und ein Status änderte sich nur, wenn jemand daran dachte, ihn zu aktualisieren. Kunden konnten nicht sehen, wo ihre Fracht tatsächlich war, und das Team hatte keinen zentralen Ort, um Ankünfte und Abfertigungen zu verwalten.

Die erste Flugplanseite (v1 bis v3.5, Februar–März 2026) bekam Filter nach Land und Transportart, eine Logik für Verspätungen, Kacheln für Mobilgeräte und drei Sprachen. Nach Prototypen für die Verfolgung von Luftfrachtbriefen und Live-Flügen wurde alles als v4 neu gebaut: eine Express-App, die die öffentliche Seite ausliefert, eine REST-API auf Postgres, die die Antwortstruktur der alten Webhooks beibehält, und ein Admin-Bereich in React und TypeScript mit Rollen, Audit-Log, Dashboard, Filtern im Stil von ClickUp, einem schrittweisen Anlegen neuer Einträge und einem automatischen wöchentlichen Abfertigungsplan. Ich habe v4 geplant, danach bauten Claude-Code-Agenten den Großteil in langen, überwiegend autonomen Sitzungen, während ich steuerte, prüfte und die Designentscheidungen traf.

Ein Poller, der Status nur vorwärts setzt, führt jeden Flug anhand der Ereignisse des Luftfrachtbriefs durch eine Pipeline mit sechs Stufen; er nutzt das Tracking von Turkish Cargo und für andere Fluggesellschaften TrackCargo. Flugbahnen von Flightradar24 werden für die Karte zwischengespeichert, und das Team kann Chronik-Notizen anlegen, die wahlweise auch Kunden sehen. Der Server entfernt Luftfrachtbriefnummern, Fluggesellschaften und Flughafencodes, bevor irgendetwas die Kundenseite erreicht. Die App läuft auf Vercel mit Neon Postgres.