Flykitt · a travel performance platform and its storefront

Flykitt sells arrival performance. A system of supplements, an app, and protocols that get travelers (athletes, executives, military) off a long-haul flight functional. I joined in 2021 as the platform's backend architect and stayed four years, through the storefront rebuild, the subscription launch, and the AI product lines.

The clientele made reliability non-negotiable: when a professional sports team lands at 2am before a match, the protocol has to be there. At the same time the business ran on a physical-product storefront and a subscription tier, so the same small engineering team owned revenue infrastructure, identity, mobile APIs, and ops. The architecture had to make that ownership tractable.

Under the app and the storefront is a distributed system. A Fastify API takes every mobile request; a separate orders API takes every shop order; behind both, an SNS to SQS spine fans work into a swarm of workers, each with its own queue and its own dead letter line. Programs are built by an algorithm worker, drawn into a protocol pdf by the files service, and handed to the warehouse api for a physical custom pack. Auth0 sits in front of every surface with one tenant per client; a notification service speaks to Slack, SES, and Firebase Cloud Messaging. AWS X-Ray stitches the trace across all of it. What follows breaks the system into three views.

The front is deliberately monolithic. One Fastify app with thirty route modules on Lambda is easier to trace, deploy, and reason about than a service per domain when the team is small. Every request lands at the API Gateway, is verified once against Auth0, then handled by a route module in the same process. The seams live behind that front: each async handoff crosses an SNS topic and lands in a dedicated SQS queue with its own dead letter line, and AWS X-Ray follows the trace across the boundary.

The mobile POST returns as soon as the API has persisted the inputs and published to the topic. The pipeline runs on worker time, not on request time. Every worker has its own SQS queue plus dead letter queue and is idempotent on the program id, so a replay by the queue cannot double bill or double ship. When the algorithm finishes, a second SNS topic wakes the push worker, which delivers an APNS payload through Firebase Cloud Messaging. The phone updates without polling.

The support tooling surface uses the same API but a different front door. An MCP server wraps the Flykitt API for triage agents; an M2M gated read only SQL executor and an OpenAI Assistants proxy round out the toolkit for the human on the other end. Every tool speaks the same auth (M2M tokens through Auth0) and hits the same domain. No shadow admin API, no bypass path.

Six production screens from the iOS app, each shown as captured and annotated to the backend systems behind it: the itinerary, flight-status, protocol, aggregation, and rewards services the platform runs. The screens are the work of the Flykitt design team; the systems they read from are the scope of this case study.