Cruiser Aviation Platform - AWS Rebuild

A flight school operating across two legal entities (Austrian GmbH and Romanian SRL) needed a unified platform to manage members, scheduling, flight logging, and billing - under two fiscal regimes, two currencies, and two invoice providers. The legacy system couldn't enforce the correctness rules the business needed: oldest-first hour consumption reconciled to the cent, fiscal documents that match stored amounts exactly, and a billing pipeline that would never silently issue a real document from a staging environment. Beyond billing, the platform required role-gated access across roughly 20 modules, a WhatsApp self-service flow for members, and automated scheduling - all sharing the same business logic without duplicating it across runtimes. Sprawling dependencies and unclear write paths had previously made the system fragile; the rebuild had to make it impossible for database access to leak into UI components and for any single write to happen through more than one code path. Infrastructure integrity was also a hard requirement: no stored AWS credentials anywhere in CI, no bastion hosts or SSH tunnels to reach the database, and production deploys that are always deliberate rather than automatic.

The platform runs on ECS Fargate ARM64 behind CloudFront and an ALB, with Aurora Serverless v2 Postgres 17 accessed exclusively via the Data API using IAM auth - eliminating bastion hosts entirely. Next.js 16 App Router enforces a strict per-module file convention (RSC page, server-only query, use-server actions, pure lib, client form) so DB access physically cannot appear in components. Server actions handle all session-authenticated writes; route handlers are reserved for webhooks, cron, and internal APIs. The CDK deployment across two AWS accounts uses GitHub OIDC with trust pinned to immutable owner/repo IDs; staging auto-deploys on merge, prod is workflow_dispatch only, and secrets are never in CloudFormation. Billing is abstracted behind a single InvoiceProvider interface with SmartBill, Stripe, and a MockProvider (the staging default, since SmartBill has no test mode and issues real fiscal documents from either environment). A single settleProforma pipeline is the only paid→fiscal→ledger path, entered from either a Stripe webhook or an admin action. Romanian SRL invoices fetch the official BNR EUR→RON rate before issue, pin it, and refuse to proceed if bnr.ro is unreachable - ensuring stored amounts match the printed fiscal document to the cent. The external provider call sits inside the DB transaction deliberately, so a failed insert cannot silently follow a successful document issue. The FIFO hours ledger is a 317-line pure function with no imports, no I/O, and no Date.now() - balances are recomputed on read over the full flight history, using integer hundredths throughout to eliminate floating-point drift. The same function is consumed by the usage screens, the dashboard, the WhatsApp Lambda, and migration scripts, with a unit test asserting the bot's output matches the engine's - making divergence structurally impossible. Idempotency is enforced everywhere via dedupe-key claims on INSERT … ON CONFLICT DO NOTHING, and every integration follows a shared template: CHANGEME-gated credentials, lazy singleton, fixed timeout, retry on 5xx/429/timeout only, and typed error mapping at the module boundary.