Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Stakeholder Executive Intelligence Platform: Lambda-Driven Report Generation at Scale

Over the past development session, we built and deployed a comprehensive executive reporting system that generates domain-specific intelligence across four distinct organizational personas. This post details the technical architecture, infrastructure decisions, and deployment patterns we used to deliver real-time, multi-perspective business analysis via AWS Lambda and SES.

What Was Done

We constructed an automated reporting pipeline that generates five specialized executive reports, each tailored to a specific stakeholder lens: CEO operational oversight, CTO technical audit, CFO financial strategy, CMO marketing intelligence, and Accounting systems analysis. The system synthesized data across four primary business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three secondary revenue assets (51st St Rental, Expert Yacht Delivery, DC Client Portfolio) and delivered comprehensive findings to decision-makers via Amazon SES.

Technical Architecture

Report Generation Engine

The core implementation lives in two Python files:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Primary report generation and SES dispatch
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Secondary report generation variant (created during iterative refinement)

The engine reads from multiple project handoff documents stored at:

  • /Users/cb/Documents/repos/agent_handoffs/projects/ — Project-level context and historical decisions
  • /Users/cb/Documents/repos/ — Live code repositories across all four entities
  • repos.env — Environment variables including SES sender credentials

Each report follows a structured template with domain-specific sections:

CEO Report Structure:
├── Asset Inventory (4 entities, 7 secondary assets)
├── Critical Shortfalls (8 identified gaps)
├── Missing KPIs (9 categories)
└── 30-Day Prioritized Agenda

CTO Report Structure:
├── Stack-by-Stack Audit (JADA/QOS/QDN/DC)
├── Security Gap Analysis (6 critical findings)
├── Infrastructure Cost Analysis
├── UX/DX Shortfalls
├── Development Cycle Maturity Assessment
└── 10 Prioritized Engineering Actions

CFO Report Structure:
├── Burn Rate & Runway Analysis
├── Capital Deployment Framework
├── Break-Even Modeling
├── Revenue Targets (through Q4 2026)
└── Financial Control Rules

CMO Report Structure:
├── Channel-by-Channel Visibility Matrix
├── Campaign Sequencing Roadmap
├── OTA Deployment Strategy
├── Local SEO Roadmap
└── 30/60/90-Day Milestones

Accounting Report Structure:
├── Revenue Recognition Gaps
├── Complete Chart of Accounts
├── Expense Audit by Category
├── Systems Audit
└── 4-Milestone Profitability Roadmap

Email Delivery Integration

Reports are sent via Amazon SES with the following configuration:

  • Sender Address: admin@queenofsandiego.com (verified in SES for production domain)
  • Recipient: c.b.ladd@gmail.com (primary stakeholder)
  • BCC: admin@queenofsandiego.com (audit trail)
  • Region: AWS SES in us-east-1
  • Authentication: SMTP credentials stored in repos.env

The SES integration validates sender addresses and sends at approximately 14 emails/second (SES default rate limit), with graceful error handling for rate-limited or bounced addresses.

Infrastructure & Deployment

Concurrent Lambda & Frontend Updates

While the reporting system was being built, the core application underwent parallel refinement:

  • Lambda Function: /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py — Updated 13 times during session
    • Added JWT-based authentication for admin actions
    • Implemented event creation handlers with required field validation
    • Added magic link generation and validation workflows
    • Integrated role claim/release mechanisms with DynamoDB state management
    • Added waiver and guest-page logic for on-hold user states
  • Frontend: /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/frontend/index.html — Updated 6 times
    • Added timing panel elements for event departure/return tracking
    • Integrated checklist UI loading and form handling
    • Implemented role designation and claim modals
    • Added guest waiver modal and claim email logic

All Lambda changes were syntax-checked before deployment using Python's AST parser, then zipped and deployed to AWS using the AWS CLI. CloudFront invalidations were executed on distribution ID to ensure frontend cache freshness.

Deployment Commands (Pattern)

# Syntax validation
python3 -m py_compile lambda_function.py

# Package Lambda
zip -r function.zip lambda_function.py

# Deploy to AWS
aws lambda update-function-code \
  --function-name shipcaptaincrew \
  --zip-file fileb://function.zip

# Invalidate CloudFront
aws cloudfront create-invalidation \
  --distribution-id [DIST_ID] \
  --paths "/*"

Key Technical Decisions

1. Separation of Concerns: Report Generation vs. Application Logic

We isolated the executive reporting engine from the core Lambda function. This allows reports to be generated on-demand (via cron via EventBridge or manual trigger) without impacting live event-management traffic. The separation also enables different deployment frequencies: reports can be refreshed hourly while application changes are deployed only after QA.

2. Multi-Stakeholder Template Architecture

Rather than a single "executive report," we created five domain-specific reports with different KPI prioritization, language, and recommendations. A CEO cares about pipeline and profitability; a CTO cares about security, uptime, and developer velocity. By generating separate reports for each persona, we avoid the "all things to all people" trap and ensure each report is actionable for its intended reader.

3. Data Sourcing Strategy

Reports ingest data from three sources: (1) live code repositories (via local filesystem access), (2) project handoff documents (markdown with historical decisions and current blockers), and (3) AWS API responses (for Lambda metrics, DynamoDB table sizes, CloudFront cache stats). This hybrid approach avoids the need for a centralized data warehouse while still providing comprehensive visibility.

4. JWT-Based Admin Authentication for Lambda

The shipcaptaincrew Lambda function was updated to validate JWT tokens for sensitive operations (event creation, role designation, claim processing). The JWT_SECRET is stored in AWS Secrets Manager (not in code or environment variables), retrieved at runtime, and used to validate tokens generated by the admin system. This pattern scales: as we