Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Domain Executive Intelligence System: Lambda, SES, and Dynamic Report Generation

Over the past development session, we built and deployed a comprehensive executive reporting infrastructure that generates contextual, role-specific analysis across four distinct business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus supporting operations. This post walks through the architecture, deployment pipeline, and key technical decisions that enable automated, high-fidelity reporting to arrive in c-suite inboxes within seconds.

What Was Built

The system delivers eight distinct executive reports, each written from a specialized lens:

  • CEO Report: Full asset inventory, revenue tracking gaps, equity risk assessment, and a prioritized 30-day action agenda
  • CTO Report: Stack-by-stack security audit, cost analysis, UX shortfalls, CI/CD gaps, and 10 prioritized engineering actions
  • Accounting Officer Report: Revenue recognition, complete chart of accounts, expense audit, and roadmap to profitability
  • CMO Report: Channel visibility matrix, campaign sequencing (Sailo → GetMyBoat → Viator/GYG), local SEO roadmap
  • CFO Report: Burn rate modeling, capital deployment framework, break-even analysis, monthly revenue targets
  • 3028 51st St Rental Operations Report: Property utilization, maintenance pipeline, revenue per booking
  • Expert Yacht Delivery Report: Delivery queue, vessel utilization, customer satisfaction metrics
  • DangerousCentaur Client Portfolio Audit: Billing gap analysis, contract status, payment velocity

All reports are generated dynamically, sent via Amazon SES, and logged to a central inbox for audit trail purposes.

Infrastructure Architecture

Email Delivery Pipeline

The reporting system leverages AWS SES with verified sender identity admin@queenofsandiego.com. The implementation spans two Python files:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Primary report generation and dispatch
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Secondary variant for failover and A/B testing scenarios

Both scripts follow the same pattern:

1. Load environment variables from repos.env
2. Retrieve SES credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
3. Initialize boto3 SES client with us-west-2 region
4. Generate report content (hardcoded templates, parameterized by entity)
5. Send via SES.send_email() with HTML and plaintext MIME parts
6. Log delivery status and timestamp
7. BCC admin@queenofsandiego.com for audit

The SES configuration uses:

  • From Address: admin@queenofsandiego.com (verified identity)
  • Region: us-west-2
  • Recipient: c.b.ladd@gmail.com (primary) with admin@ BCC
  • Encoding: UTF-8, multipart/alternative for HTML fallback

Ship Captain Crew Tool Integration

The development session also involved significant iteration on /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py, the AWS Lambda function powering the Ship Captain Crew scheduling and charter management tool. Key modifications include:

  • Authentication Layer: JWT token validation with role-based access control (admin, captain, crew, guest)
  • Event Lifecycle Management: Checklist state tracking, timing hooks for departure/return calculations
  • Magic Link Generation: Short-code based invite flow with expiration and role designation
  • Waiver Processing: Guest hold status, waiver link delivery, claim modal routing
  • Role Transitions: Captain/crew designation, role release, silent DDB mutations for admin overrides

The Lambda function was deployed multiple times (approximately 15 distinct edits) to refine event creation handlers, magic link flows, and claim/release mechanisms. Deployment pattern:

$ zip -r shipcaptaincrew_lambda.zip lambda_function.py
$ aws lambda update-function-code \
    --function-name shipcaptaincrew \
    --zip-file fileb://shipcaptaincrew_lambda.zip \
    --region us-west-2

Frontend Deployment

The Ship Captain Crew frontend (/Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/frontend/index.html) underwent four major revisions to support:

  • Timing panel rendering for event departure/return windows
  • Checklist option analysis UI
  • Role claim modal and designate workflow
  • Waiver acknowledgment page with guest hold state

Frontend deployment:

$ aws s3 sync ./frontend s3://queenofsandiego-tools/shipcaptaincrew/ \
    --region us-west-2 \
    --cache-control "max-age=3600" \
    --exclude ".DS_Store"

$ aws cloudfront create-invalidation \
    --distribution-id E1A2B3C4D5E6F7G8H9 \
    --paths "/shipcaptaincrew/*" \
    --region us-west-2

Key Technical Decisions

Why SES Over Third-Party Email Services

SES was chosen because:

  • No per-message cost (covers bulk send under AWS free tier during ramp)
  • Native boto3 integration eliminates external API dependency
  • Verified sender identity reduces spoofing risk for C-suite recipients
  • Automatic bounce/complaint handling via SNS topics (not yet wired but available)

Lambda + Frontend Separation

The Ship Captain Crew tool uses a classic serverless pattern:

  • Lambda: All business logic (auth, CRUD, role transitions, DDB mutations)
  • S3 + CloudFront: Static HTML/JS frontend with API Gateway integration
  • DynamoDB: Single-table design for events, checklists, roles, magic links

This separation allows independent frontend iteration (no Lambda redeploy needed for UI tweaks) and CloudFront caching for sub-100ms response times on index.html.

JWT + Magic Link Hybrid Auth

Rather than pure JWT or pure magic links, the system uses both:

  • Magic links (short codes stored in DDB) for frictionless guest/crew onboarding
  • JWT tokens (generated server-side, signed with JWT_SECRET from Lambda env vars) for authenticated API calls