Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Multi-Domain Executive Intelligence Platform: Building Concurrent C-Suite Reporting Infrastructure

Over a compressed development cycle, we built and deployed a real-time reporting system capable of generating domain-specific executive intelligence across four operational entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three ancillary business units (Expert Yacht Delivery, 3028 51st St Rental, DangerousCentaur Client Portfolio). This post details the technical architecture, infrastructure decisions, and deployment patterns we used to deliver five concurrent C-suite reports within a single execution window.

What Was Done

We created a unified reporting pipeline that:

  • Synthesized operational data across disconnected systems (DynamoDB, S3, manual spreadsheets, email records)
  • Generated domain-specific intelligence for five C-suite personas (CEO, CTO, CFO, CMO, Accounting Officer)
  • Delivered 9,000+ words of structured analysis to verified SES endpoints within minutes
  • Established a reusable pattern for future bulk reporting without manual data marshaling
  • Identified infrastructure debt, security gaps, and process bottlenecks across all domains in a single analytical pass

Technical Architecture

Report Generation Pipeline

The core execution happened in two Python scripts:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Primary orchestrator
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Secondary variant (experimented with during iteration)

Each report followed a structured template pattern:

Report Template Structure:
├── Executive Summary (2-3 sentences)
├── Current State Assessment
├── Gap Analysis / Findings
├── Quantified Metrics (KPIs, burn rates, revenue potential)
├── Prioritized Action Items (30/60/90 days or immediate)
└── Financial Impact / Next Steps

Why this structure: C-suite readers need immediate context, specific numbers, and actionable next steps. Each persona (CEO focused on profitability/assets, CTO on technical debt/UX, CFO on cash flow) received filtered data through their domain lens while maintaining a consistent analytical framework.

Data Sources and Aggregation

Reports pulled from:

  • DynamoDB — Event records, checklist state, crew assignments (tables: shipcaptaincrew_events, shipcaptaincrew_checklists)
  • S3 Buckets — Static asset inventory, image archives (queenofsandiego.com, quickdumpnow.com buckets)
  • Route53 — Domain health and DNS configurations (verified all four primary domains + alternates)
  • CloudFront Distributions — Cache hit rates, edge location distribution
  • Lambda Function Logs — Execution patterns, error rates, cold start metrics
  • Manual project handoffs (/Users/cb/Documents/repos/agent_handoffs/projects/) — Business context, financial constraints, equity/partnership notes

Why aggregated: No single system contained complete operational truth. Manual project files documented partnership obligations and revenue constraints that DynamoDB missed; S3 bucket sizes revealed infrastructure waste CloudWatch couldn't quantify; Route53 records exposed abandoned domain redirects.

SES Integration for Delivery

All five reports shipped via AWS SES from verified sender admin@queenofsandiego.com:

Command: Send 5 executive reports via SES
Recipients: c.b.ladd@gmail.com
BCC: admin@queenofsandiego.com
From: admin@queenofsandiego.com (verified sender)
Method: Boto3 SES client with HTML body content

Environment variables referenced from repos.env:

  • AWS_REGION — Set to us-west-2 (primary operational region)
  • SES_SENDER_EMAIL — Verified address required for production sends
  • No hardcoded credentials in script; relies on IAM role attached to execution environment

Why SES over alternatives: Low per-message cost ($0.10/1000), reliable HTML rendering, BCC logging capability for audit trails, native AWS integration without external SMTP providers.

Infrastructure Decisions

ShipCaptainCrew Lambda Refactoring (Concurrent Work)

During the reporting cycle, we made 20+ commits to /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py. Key changes:

  • Added timing panel UI elements — Departure/return countdown displays in frontend/index.html
  • Implemented checklist state machine — loadChecklist() function with proper timing hooks
  • JWT authentication hardening — Generated proper token format from JWT_SECRET (stored in Lambda environment variables, not hardcoded)
  • Magic link flow — Endpoint for invite generation, short code storage in DynamoDB, email delivery via SES
  • Role designation system — Crew member claim/release routes with state validation
  • Waiver capture integration — Guest page handlers with on-hold logic for pending waivers

Syntax validation before each deploy:

python -m py_compile lambda_function.py
# No output = success; any SyntaxError surfaces immediately

Deployment pattern:

1. Validate syntax locally
2. Zip lambda_function.py + dependencies
3. Deploy to AWS Lambda via console or CLI
4. Run post-deployment endpoint smoke tests
5. Invalidate CloudFront cache for frontend
6. Log deployment in work-log for audit trail

Frontend Static Deployment (S3 + CloudFront)

Updated frontend/index.html was deployed to:

  • S3 bucket: queenofsandiego.com (origin for CloudFront distribution)
  • CloudFront distribution: Queried for cache invalidation after each update
  • Invalidation pattern: /* (full cache flush) to ensure zero stale HTML serving

Why full invalidation: Single-page app structure means root index.html changes ripple to all routes. Partial invalidation risks serving stale HTML with outdated timing panel or authentication logic.

Key Decisions

1. Concurrent Report Generation Over Staged Approach

We generated all five reports in a single script execution rather than staggered batches. Rationale: Leadership needs synchronized intelligence to avoid contradictory decisions. A CEO read of asset inventory should align with the CTO's infrastructure cost analysis; the CFO's burn model should match