Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Stakeholder C-Suite Reporting System: Infrastructure, Email Delivery, and Executive Intelligence

Over the past development cycle, we built and deployed a comprehensive executive reporting framework designed to surface business intelligence across five distinct C-suite perspectives. This post covers the technical architecture, infrastructure decisions, and deployment patterns used to generate, validate, and deliver these reports to leadership.

The Problem: Fragmented Visibility Across Four Operating Entities

Our portfolio spans four independent operating entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three ancillary business units (3028 51st St Rental, Expert Yacht Delivery, and the DC Client Portfolio). Each operates with its own tech stack, revenue model, and operational cadence—but leadership had no unified view of performance, risk, or improvement priorities. We needed a system to:

  • Generate role-specific analysis (CEO, CTO, Accounting, CMO, CFO perspectives)
  • Surface critical KPIs, gaps, and financial health
  • Deliver via reliable, auditable email infrastructure
  • Support rapid iteration as business priorities shifted

Architecture: Report Generation Pipeline

The core report system is built on Python scripts that run locally and integrate with AWS SES (Simple Email Service) for delivery. Here's the structure:

/Users/cb/Documents/repos/tools/
├── send_exec_reports.py      # Primary report generation and delivery
├── send_exec_reports_2.py    # Alternate/modular approach (used for iteration)
└── repos.env                 # Environment configuration (SES vars, sender address)

Why this approach? Python gives us rapid iteration—we can modify report logic, audit content, and test email delivery without touching Lambda or CI/CD. SES provides cost-effective, reliable email with built-in bounce/complaint tracking. The reports themselves are generated as formatted strings with rich text structure, then piped directly into SES SendEmail API calls.

SES Integration: Email Delivery and Configuration

We use AWS SES with a verified sender address configured in repos.env:

SES_REGION=us-west-2
SES_FROM_ADDRESS=admin@queenofsandiego.com
SES_TO_ADDRESS=c.b.ladd@gmail.com  # Primary recipient
# (BCCs configured in script logic for audit trail)

The sender address admin@queenofsandiego.com is verified in SES as a domain identity, not a simple email address. This gives us higher deliverability and production-grade bounce handling. All reports are sent to the primary recipient with BCC to a tracking address, creating an immutable audit log.

Key decision: We hardcoded the sender as a verified domain identity rather than using IAM user verification. Domain verification scales better and survives role/credential rotations.

Report Content Architecture: Five Distinct Perspectives

Each report is generated by a separate function that queries across the portfolio and surfaces context-specific intelligence:

  • CEO Report: Asset inventory across all entities, revenue pipeline health, equity/personnel risk, KPI gaps, 30-day prioritized agenda. Output: ~800 lines of formatted text.
  • CTO Report: Stack-by-stack audit (JADA/QOS/QDN/DC), security posture analysis, cost analysis, UX shortfalls, dev cycle gaps, 10 prioritized engineering actions.
  • Accounting Report: Revenue recognition issues, chart of accounts, expense audit, profitability roadmap through Q1 2027.
  • CMO Report: Channel visibility matrix, blast email sequencing, OTA deployment roadmap (Sailo → GetMyBoat → Viator/GYG), QDN local SEO milestones.
  • CFO Report: Burn rate model, capital deployment framework (zero-cost → low-cost → revenue-producing), break-even analysis, monthly revenue targets, financial guardrails.

Each report is generated as a single string with section headers, bullet points, and quantified metrics. We use plain-text formatting (no HTML email templates) for maximum deliverability and auditability.

Command Execution and Validation

Report generation follows a three-step pattern:

# Step 1: Verify SES environment variables
$ grep -E "SES_|FROM_ADDRESS" repos.env

# Step 2: Syntax check the reporting script
$ python3 -m py_compile send_exec_reports.py

# Step 3: Execute and deliver
$ python3 send_exec_reports.py

The script internally:

  1. Loads SES credentials from boto3 session (assumes AWS_PROFILE or EC2 IAM role)
  2. Constructs report content from handoff files, project metadata, and portfolio inventory
  3. Calls boto3.client('ses').send_email() for each report with unique To, Subject, and Body
  4. Logs Message IDs for delivery tracking

Why Not Lambda or Scheduled Tasks?

We intentionally kept report generation outside of Lambda and EventBridge:

  • Rapid iteration: Executives request report changes mid-week. Python scripts allow instant modifications without CI/CD pipelines or Lambda versions.
  • Auditability: Local git history shows exactly which metrics and analysis each version included.
  • Cost: No cold-start latency, no CloudWatch Logs overhead, no Lambda layer management.
  • Security: Reports are generated by an engineer with full context access, not a generic automation service. Reduces risk of accidental data exposure.

Over time, as reporting becomes routine, we will migrate to a scheduled Lambda function with SES integration, but only after the report structure stabilizes.

Integration with Existing Infrastructure

The reporting system pulls context from our existing project tracking infrastructure:

/Users/cb/Documents/repos/agent_handoffs/projects/
├── shipcaptaincrew.md        # SCC operational handoff
├── [other project handoffs]  # Entity-specific metadata
└── [financial tracking]      # Revenue, burn, KPI targets

These markdown files serve as the single source of truth for current project state. The reporting script parses them to extract metrics, timelines, and risk flags. When stakeholders request report changes, we update the handoff files, then regenerate reports—no code changes required.

Delivery and Audit Trail

Each report execution generates an audit record:

  • SES Message ID (for bounce/complaint tracking)
  • Timestamp and report type
  • Recipient list
  • Content hash (for version control)

We log this to a local file, which can be archived or synced to S3 for long-term retention. SES also provides CloudWatch metrics and bounce/complaint notifications, which we monitor for deliverability issues.

Security Considerations

What we're protecting: Executive financial data, personnel risk factors, competitive strategy, and investment roadmaps. These are business-critical, confidential documents.

  • Transport: SES enforces TLS; emails are encrypted in transit.
  • Storage: Reports are never persisted to disk after sending (except audit