Boxette Flights

Customers kept asking where their parcel was and when its flight would land. The schedule page was one static file fed by open n8n webhooks, operators kept the flight data in a Google Sheet by hand, and a status changed only when someone remembered to update it. Customers could not see where their cargo actually was, and operators had no single place to manage arrivals and dispatches.

The first schedule page (v1 to v3.5, February–March 2026) added country and transport filters, delay logic, mobile cards and three languages. After prototyping air-waybill and live-flight tracking, everything was rebuilt as v4: one Express app serving the public page, a REST API on Postgres that keeps the old webhook response shape, and a React and TypeScript admin with roles, an audit log, a dashboard, ClickUp-style filters, a step-by-step create flow and an automatic weekly dispatch schedule. I planned v4, then Claude Code agents built most of it in long, mostly autonomous sessions while I directed, reviewed and made the design decisions.

A forward-only poller moves each flight through a six-stage pipeline from air-waybill events, using Turkish Cargo’s tracking and TrackCargo for other carriers. Flightradar24 trajectories are cached for the map, and operators can post chronicle notes that customers may optionally see. The server strips air-waybill numbers, carriers and airport codes before anything reaches the customer page. The app runs on Vercel with Neon Postgres.