Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Building a Multi-Domain Executive Intelligence System: Architecture, Deployment, and Financial Reporting Infrastructure

Over the past development cycle, we built and deployed a comprehensive executive reporting system across a portfolio of four distinct business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three supporting service domains. This post covers the architectural decisions, infrastructure patterns, and deployment methodology that enabled real-time insights delivery to C-suite stakeholders.

What Was Done

We created an integrated reporting pipeline that generates five specialized executive perspectives simultaneously, each tailored to a distinct stakeholder function:

  • CEO Report — asset inventory, revenue tracking gaps, equity/transition risks, KPI framework
  • CTO Report — techstack audit, security hardening roadmap, cost optimization, developer workflow analysis
  • CFO Report — burn rate modeling, capital deployment tiers, monthly revenue targets, break-even analysis
  • CMO Report — channel visibility matrix, OTA sequencing strategy, SEO roadmap, 90-day milestones
  • Accounting Report — chart of accounts, expense audit, accounting system roadmap

Plus three domain-specific audits covering rental property management, yacht delivery operations, and client portfolio billing.

Technical Architecture

Report Generation Pipeline

The core system lives in /Users/cb/Documents/repos/tools/send_exec_reports.py and send_exec_reports_2.py. Each script:

  • Reads environment variables from repos.env to source SES credentials, verified sender addresses, and recipient lists
  • Generates report content dynamically based on stakeholder role and domain context
  • Uses AWS SES (Simple Email Service) to send via a verified sender identity
  • Implements BCC to admin@queenofsandiego.com for compliance and archival

Why SES instead of third-party email services? We already operate within AWS infrastructure for Lambda deployments, CloudFront distributions, and S3 buckets. SES integrates natively, eliminates external API dependencies, and costs approximately $0.10 per 1,000 emails at our current volume. The verified sender constraint ensures deliverability while maintaining strict access controls.

Environment Configuration

All email infrastructure credentials are stored in a repos.env file (not committed to version control). The script validates three critical variables before sending:


# Validated on each run
SES_REGION=us-west-2
SES_ACCESS_KEY=***
SES_SECRET_KEY=***
FROM_ADDRESS=admin@queenofsandiego.com
RECIPIENT_LIST=c.b.ladd@gmail.com,additional.exec@example.com

Commands like Check SES email vars from repos.env and Check SES variable names in repos.env were executed to ensure all sender/recipient configurations were correct before batch deployment.

Lambda & Frontend Deployment Pipeline

In parallel, we conducted extensive work on the ShipCaptainCrew tool, which powers crew scheduling and event management for QueenofSandiego operations.

Backend: AWS Lambda Function Updates

The Lambda function lives at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py. Over this cycle, we:

  • Added JWT authentication with token validation for admin operations
  • Implemented magic-link invitation flows with short-code generation stored in DynamoDB
  • Built role-claim and role-release handlers for crew designation workflows
  • Added waiver-holding logic to prevent guest bookings until compliance requirements are met
  • Integrated EventBridge scheduling for automated nudge notifications (ptb_nudge cron rule)
  • Created event creation with required field validation (event_id, departure time, return time, etc.)

Why JWT + Magic Links? Magic links eliminate password management friction for crew while maintaining a zero-knowledge authentication pattern. JWT tokens are stateless and can be validated entirely within the Lambda handler without external service calls, reducing latency and cost. Short codes stored in DynamoDB provide an audit trail and allow revocation without re-issuing tokens.

Frontend: HTML & JavaScript Updates

The frontend at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/frontend/index.html received multiple iterations:

  • Added role-selection UI for crew designation workflows
  • Integrated guest waiver page with on-hold state detection
  • Built timing panel elements to calculate sunset-based event schedules for San Diego operations
  • Wired claim modal to interact with role-claim endpoint
  • Added magic-link validation and token persistence for session management

The timing calculations use sunset data for San Diego (latitude 32.7157°N, longitude -117.1611°W) to dynamically compute departure and return windows. This eliminates manual scheduling and ensures compliance with local maritime regulations.

Deployment & Infrastructure

Lambda Deployment

Lambda syntax validation was performed repeatedly during development:


python -m py_compile lambda_function.py
# Verify no syntax errors before each deploy

The zipped function was deployed to AWS Lambda with environment variables for:

  • JWT_SECRET — stored in AWS Secrets Manager, referenced by the Lambda IAM execution role
  • DYNAMODB_TABLE — the table storing event data, invitations, and crew assignments
  • SES_REGION / SES_SENDER — email delivery configuration
  • EventBridge rule ARN for scheduled nudge notifications

Each deploy included a maintenance work-log entry documenting:

  • Which handlers were modified
  • New environment variables introduced
  • Breaking changes to existing API contracts
  • Rollback procedures if issues arise

Frontend Deployment to S3 + CloudFront

The frontend assets were deployed to an S3 bucket (exact bucket name omitted for security) with a CloudFront distribution (distribution ID tracked in deployment logs). After each frontend push:


# Deploy updated index.html to S3
aws s3 cp frontend/index.html s3://[bucket-name]/tools/shipcaptaincrew/index.html --acl public-read

# Invalidate CloudFront cache to force edge nodes to fetch fresh content
aws cloudfront create-invalidation --distribution-id [DISTRIBUTION_ID] --paths "/tools/shipcaptaincrew/*"

Why both S3 and CloudFront? S3 provides durable, versioned storage with automatic replication. CloudFront distributes content across global edge locations, reducing latency for crew accessing the scheduling tool from various coastal locations. The cache invalidation ensures new code reaches users within seconds of deployment, not minutes or hours.

Key Decisions & Tradeoffs

  • JWT over session cookies: Stateless authentication scales