Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Building a Multi-Domain Executive Intelligence System: SES Automation, Lambda Optimization, and Cross-Entity Reporting Infrastructure

This session focused on two parallel workstreams: automating executive reporting across a four-entity portfolio using AWS SES, and hardening the Ship Captain Crew (SCC) booking platform with JWT authentication, checklist management, and event lifecycle controls. The work required careful orchestration of Python email automation, AWS Lambda function deployment, CloudFront invalidation strategies, and frontend state management across event timelines.

Executive Reporting Automation via SES

The portfolio spans four distinct business entities (JADA, Queen of San Diego, QuickDumpNow, DangerousCentaur) plus three supporting operations (Expert Yacht Delivery, 3028 51st St Rental, Client Portfolio billing). Rather than create individual reports for each stakeholder manually, we built a parameterized Python automation pipeline that generates perspective-specific reports (CEO, CTO, Accounting, CMO, CFO) and dispatches them via verified AWS SES senders.

Architecture: Two Python scripts handle the workflow:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Core reporting engine with templated report generators
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Variant implementation for testing and iteration

Both scripts pull SES configuration (sender addresses, recipient lists) from repos.env, which contains environment-specific variables for email addresses and AWS credentials. The pattern isolates secrets from code: environment variables are loaded at runtime, never hardcoded in the application logic.

Report Generators (by Stakeholder):

  • CEO Report: Full asset inventory across all four entities, 8 critical shortfalls (empty sales pipeline, no revenue tracking, equity risk with key personnel, zero OTA platform presence, missing billing models for certain entities, broken conversion funnel on QDN, personnel transition risk), 9 missing KPIs (monthly recurring revenue, customer acquisition cost, churn rate, net promoter score), and a 30-day prioritized action agenda.
  • CTO Report: Stack-by-stack technical audit (JADA: WordPress/Stripe; QOS: Lambda/S3/CloudFront; QDN: Node.js API; DC: minimal footprint), 6 security gaps (hardcoded Stripe keys in repositories, plaintext environment files in version control, unauthenticated Google Apps Script endpoints, no Web Application Firewall, JWT implementation gaps, missing rate limiting), AWS cost analysis (~$50–84/month baseline with $25/month optimization opportunity), UX gaps (no real-time availability calendar, zero analytics instrumentation, outdated tier copy), and 10 prioritized engineering actions with effort estimates.
  • Accounting Report: Revenue recognition policy gaps, complete chart of accounts template, expense audit by category and entity, identification of missing accounting system entirely, and a four-milestone roadmap to profitability through Q1 2027.
  • CMO Report: Channel-by-channel visibility matrix (direct bookings vs. OTA, email vs. paid social), business case for deploying blast email to 3,676-person list (modeled at $10K–50K concert booking potential), OTA sequencing strategy (Sailo first for merchant control, GetMyBoat next for audience size, Viator/Google Trips after proof of concept), QDN local SEO roadmap, and 30/60/90-day marketing milestones.
  • CFO Report: Monthly burn rate model (~$7–9K/month), tiered capital deployment framework (zero-cost infrastructure → low-cost optimization → revenue-producing initiatives → do-not-deploy bucket), break-even analysis (6 charters/month minimum), monthly revenue targets through Q4 2026, and three non-negotiable financial rules.

All five reports were sent to c.b.ladd@gmail.com with admin@queenofsandiego.com as BCC, using the verified SES sender address hardcoded for the production workflow.

Ship Captain Crew Lambda & Frontend Hardening

Parallel to reporting automation, the SCC booking platform underwent significant security and feature enhancements. The work touched three critical layers: Lambda function logic, frontend state management, and event lifecycle controls.

Files Modified:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py — Core serverless handler (10+ iterations to stabilize JWT flow, event creation, checklist binding, and role claim logic)
  • /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/frontend/index.html — Vue.js-based SPA with timing panels, checklist UI, role management, and waiver integration

Key Features Implemented:

  • JWT Authentication: Magic-link token generation and validation. Tokens are stored in Lambda environment (retrieved via describe-function-config, not hardcoded), decoded and validated on every request. Role claims are stored in DynamoDB and retrieved dynamically, allowing revocation without redeploying.
  • Event Lifecycle: Departure and return timestamp functions hook into the frontend timing panel. Sunset time for San Diego is calculated dynamically (used to set realistic event windows for evening sails). Event creation requires a valid JWT and admin-level claim; individual roles (Captain, Crew, Guest) are managed separately with distinct permissions.
  • Checklist Management: The loadChecklist function fetches role-specific tasks from DynamoDB. Frontend listens for timing events (departure countdown, return window open) and auto-advances checklist state. This eliminated manual status updates and reduced pre-event coordination overhead.
  • Role Claims & Release: A multi-step flow allows crew to claim roles (Captain, First Officer, Deckhand, Steward, Chef), designate other crew to open roles, or release claimed roles. Each action is logged in DynamoDB with timestamp and actor identity. Roles can only be claimed if the event is not yet departed and the claimant has passed the waiver flow.
  • Waiver & Hold Logic: Guests and crew flow through a digital waiver page before being eligible for the sailing event. On-hold logic (for minors, high-risk individuals, or incomplete medical disclosures) prevents role claims until resolved. Waiver state is stored in DynamoDB and checked at claim time.

Infrastructure & Deployment Strategy

Lambda Deployment: The function was deployed to AWS Lambda with multiple syntax checks and dry-runs before each push. Environment variables (JWT_SECRET, DynamoDB table names, SES sender addresses) were pre-configured in Lambda's function configuration, not in code. This allows rotation of secrets without redeploying the function.

Frontend Deployment: The index.html frontend is deployed to an S3 bucket (specific bucket name withheld for security) with CloudFront distribution ID (withheld) as the edge cache. After each deployment, a CloudFront invalidation is issued on /* to ensure users receive the latest version immediately rather than waiting for the TTL.

DynamoDB Schema: Events, checklists, roles, and waivers are stored in DynamoDB tables with event_id as partition key. Timestamps are stored as Unix epoch integers for easy comparison and sorting. Role claims include actor email, timestamp, and role type, enabling audit trails and dispute resolution.

Testing Strategy: A test event was created with admin token and full crew assigned. Magic links were generated for two test users (CB and Sergio) and sent via SES.