Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Stakeholder Executive Intelligence System: AWS Lambda, SES, and Real-Time Reporting

Over the past development session, I built and deployed a comprehensive executive reporting system that generates perspective-specific intelligence across four distinct organizational entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) and delivers them via AWS SES. This post walks through the architecture, deployment strategy, and technical decisions that enable automated, role-based reporting at scale.

The Problem Statement

Managing a portfolio of four semi-independent ventures requires visibility that transcends a single dashboard. Each stakeholder—CEO, CTO, CFO, CMO, accounting lead—needs radically different lenses on the same underlying data. Manual report generation doesn't scale; automated, bespoke intelligence does.

The challenge: generate five distinct executive reports, each tailored to a specific persona and expertise area, and deliver them reliably via email without hardcoding sensitive data into application logic.

Architecture Overview

The system is built on three core components:

  • Report Generation Layer — Python scripts in `/Users/cb/Documents/repos/tools/send_exec_reports.py` that construct multi-section reports dynamically
  • Email Delivery — AWS SES with verified sender identity (`admin@queenofsandiego.com`) and recipient configuration stored in environment variables
  • Data Aggregation — Read-only queries across project handoffs, finance tracking files, and infrastructure state to synthesize cross-domain insights

The report payloads themselves live in environment variables (read from `repos.env`) to keep secrets out of version control, but the structure and persona logic live in code.

Technical Implementation: Report Generation

The primary entry point is `send_exec_reports.py`. This script:

  1. Loads SES configuration from environment (sender address, recipient email, AWS credentials via IAM role)
  2. Reads project state from markdown handoffs in `/Users/cb/Documents/repos/agent_handoffs/projects/` and HTML/Lambda state across deployed services
  3. Constructs five persona-specific reports by combining standardized sections with tailored analysis
  4. Invokes AWS SES `SendEmail` for each report with BCC to audit trail

The report structure follows a consistent pattern:


[Report Header]
- Persona context (e.g., "Incoming CEO auditing profitability")
- Time of generation
- Scope (all four entities or domain-specific)

[Executive Summary / Key Findings]
- Top 3–5 critical issues ranked by business impact

[Detailed Analysis]
- Asset inventory (for CEO) / Stack audit (for CTO) / Revenue recognition (for accounting)
- Metrics, gaps, shortfalls

[Recommendations / Roadmap]
- Prioritized action items with timelines
- Success metrics / KPIs

[Supporting Data]
- Charts, lists, or appendices

Each report is generated as a multi-part MIME email with rich text formatting, making it readable both in plain-text and HTML email clients.

The Five Persona Reports

CEO Report — Incoming executive perspective, focused on profitability and asset utilization. Covers:

  • Full asset inventory across JADA, QOS, QDN, DC
  • 8 critical shortfalls (empty pipeline, no revenue tracking, Sergio equity exposure, zero OTA listings, DC billing model gap, QDN funnel breakdown, Carole transition risk, no real-time financial dashboard)
  • 9 missing KPIs (pipeline conversion rate, revenue per charter, customer acquisition cost, churn, etc.)
  • 30-day action agenda prioritized by ROI impact

CTO Report — Senior platform architect perspective (7-figure, 100x engineer from Google/Meta/Apple-tier firms). Covers:

  • Stack-by-stack audit: JADA (no infrastructure), QOS (Lambda + S3 + CloudFront + DynamoDB), QDN (static + contact email), DC (Webflow with external booking)
  • 6 security hardening gaps: hardcoded Stripe keys in repos, plaintext environment files in version control, unauthenticated GAS endpoints, no WAF, JWT implementation incomplete, missing secret rotation
  • Cost analysis (~$50–84/month AWS spend, $25/month in easy savings via unused resources)
  • UX shortfalls: no availability calendar integration, zero analytics on any domain, stale product copy, no mobile-first redesign
  • Development cycle gaps: no CI/CD, no staging environment, no automated rollback, manual deployment process
  • 10 prioritized engineering actions with effort estimates

Accounting Report — C-suite accounting officer focused on revenue recognition and financial control. Covers:

  • Revenue recognition issues (charter payments vs. refunds, deposit vs. full payment timing)
  • Complete chart of accounts needed for GAAP compliance
  • Expense audit by category (AWS, Stripe fees, domain costs, payroll)
  • Critical finding: zero accounting system in place
  • 4-milestone roadmap: QuickBooks setup (month 1), expense categorization (month 2), revenue tracking pipeline (month 3), monthly close process (month 4)

CMO Report — Marketing leader focused on channel deployment and pipeline fill. Covers:

  • Channel-by-channel visibility matrix (email blast readiness, OTA sequencing, local SEO, partnerships)
  • Case for immediate 3,676-person email blast deployment (modeled at $10K–50K concert bookings potential ROI)
  • OTA sequencing: Sailo first (tech-forward audience), GetMyBoat next (volume), Viator/GYG after crew-of-interest COI establishes baseline
  • QDN local SEO roadmap (San Diego market capture)
  • 30/60/90-day pipeline milestones

CFO Report — Financial officer focused on capital deployment and burn rate. Covers:

  • Burn rate model: ~$7–9K/month current spend
  • Tiered capital deployment framework: zero-cost initiatives → low-cost initiatives → revenue-producing initiatives → do-not-deploy initiatives
  • Break-even analysis: 6 charters/month at current ASP
  • Monthly revenue targets through Q4 2026
  • 3 non-negotiable financial rules (never deploy capital without ROI model, cap AWS spend at $100/month, maintain 6-month runway)

AWS SES Integration

The SES configuration uses verified sender identity (`admin@queenofsandiego.com`, already verified in the AWS SES console for the account region). Recipients are environment-driven, loaded from `repos.env`:


SES_SENDER_EMAIL=admin@queenofsandiego.com
SES_RECIPIENT_EMAIL=c.b.ladd@gmail.com
SES_BCC_EMAIL=admin@queenofsandiego.com
AWS_REGION=us-west-2

The Python script uses `boto3` to invoke the SES client:


import boto3

ses_client = boto3.client('ses', region_name=os.