Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Domain Executive Reporting System: Automating Strategic Insights Across Four Business Entities

Over the past development session, we built and deployed a comprehensive executive reporting infrastructure that generates five distinct analytical perspectives across JADA, QueenofSandiego, QuickDumpNow, and DangerousCentaur. This article covers the technical architecture, deployment patterns, and decision-making that powers this system.

What Was Built

The core requirement was to generate five specialized reports—each written from a different C-suite perspective (CEO, CTO, CMO, CFO, and Accounting Officer)—analyzing all assets, processes, revenue flows, and technical stacks across four distinct business entities. These reports needed to be generated on-demand and delivered via email, with an eventual cron-based automation layer.

The solution consisted of two primary components:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Initial report generation and SES delivery
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Expanded version with additional domain perspectives (3028 51st St Rental, Expert Yacht Delivery, DangerousCentaur Client Portfolio)

Technical Architecture

Report Generation Pipeline

Each report is generated as a structured narrative by analyzing project handoff documents, wiki indexes, and architectural documentation. The generation process follows this pattern:


1. Load context from repos.env (SES credentials, sender address)
2. Read project handoff markdown files from /repos/agent_handoffs/projects/
3. Query relevant site configurations and current state
4. Synthesize domain-specific perspective into structured report
5. Format as multi-paragraph narrative with executive summary
6. Send via AWS SES to designated recipients

The reports generated were:

  • CEO Report — Asset inventory, shortfall analysis (empty sales pipeline, missing revenue tracking, equity concentration risk with Sergio, zero OTA marketplace listings, billing model gaps), 9 critical KPIs not currently tracked, and a 30-day prioritized action plan
  • CTO Report — Full techstack audit across all four domains, security gap inventory (hardcoded Stripe keys, plaintext credential files in repos.env, unauthenticated GAS endpoints, missing WAF), AWS cost analysis (~$50–84/month current, ~$25/month optimization potential), UX/analytics shortfalls, CI/CD gaps, and 10 prioritized engineering actions
  • Accounting Officer Report — Revenue recognition methodology, complete chart of accounts, expense categorization by domain, acknowledgment of zero accounting infrastructure, and 4-milestone roadmap to profitability tracking through Q1 2027
  • CMO Report — Channel visibility matrix, case for immediate 3,676-person email blast deployment (modeled at $10K–50K concert booking potential), OTA sequencing strategy (Sailo → GetMyBoat → Viator/GYG), QDN local SEO roadmap, and 30/60/90-day marketing milestones
  • CFO Report — Burn rate modeling (~$7–9K/month), tiered capital deployment framework, break-even analysis (6 charters/month), monthly revenue targets through Q4 2026, and three non-negotiable financial guardrails

Email Delivery via AWS SES

Reports are delivered using AWS SES from a verified sender address (admin@queenofsandiego.com). The implementation uses boto3 to construct multi-part MIME messages:


import boto3
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

ses_client = boto3.client('ses', region_name='us-west-2')

# Construct message
msg = MIMEMultipart('alternative')
msg['Subject'] = report_title
msg['From'] = sender_address
msg['To'] = recipient_email
msg['BCC'] = admin_email

# Attach HTML body
msg.attach(MIMEText(html_body, 'html'))

# Send via SES
response = ses_client.send_raw_email(
    Source=sender_address,
    Destinations=[recipient_email, admin_email],
    RawMessage={'Data': msg.as_string()}
)

This approach allows us to maintain a single source of truth for report logic while distributing to multiple recipients. The BCC mechanism ensures audit trails without exposing email addresses in primary headers.

Integration with Existing Infrastructure

Project Handoff Documentation

The reports source data from markdown files stored in /repos/agent_handoffs/projects/, specifically:

  • shipcaptaincrew.md — Operational details on the QueenofSandiego charter booking platform
  • Domain-specific configuration and state documents tracking current implementation status

This design enables reports to remain current as handoff documents are updated, without requiring code changes. The reports are intentionally structured to be regenerable from these source files.

Credential Management

SES credentials are sourced from repos.env, which is loaded at runtime. The implementation validates that required variables are present before attempting to send:


# Load from environment
ses_access_key = os.getenv('SES_ACCESS_KEY')
ses_secret_key = os.getenv('SES_SECRET_KEY')
sender_email = os.getenv('SES_FROM_ADDRESS')

if not all([ses_access_key, ses_secret_key, sender_email]):
    raise ValueError("Missing required SES configuration in repos.env")

Key Technical Decisions

Why Generate Multiple Perspectives?

Each C-suite perspective surfaces different blind spots. The CEO focuses on revenue/KPIs, the CTO on technical debt and UX, the CFO on cash burn and break-even, the CMO on channel strategy, and Accounting on infrastructure. This multiplicity prevents any single viewpoint from dominating the prioritization conversation.

Why Use SES Over Alternative Services?

SES was already verified for admin@queenofsandiego.com and integrated into the AWS account. Using it avoids: - External service dependencies - Additional vendor management overhead - Cost (SES rates are 10¢ per 1,000 emails vs. $20–100/month for SendGrid, Mailgun, etc.) - Credential multiplication across services

Why Markdown-Sourced Content?

Handoff documents are already the source of truth for operational state. Rather than duplicating this information into a database, the reports parse the markdown directly. This ensures reports always reflect current understanding and eliminates sync overhead.

Deployment and Execution

The scripts were executed locally with AWS credentials available in the execution environment. Commands run included:


# Verify SES configuration
grep -i "SES_" repos.env

# Generate and send reports
python3 send_exec_reports.py

# Verify delivery
# (Check BCC inbox for confirmation)

All five reports were successfully delivered to c.b.ladd@gmail.com with admin@queenofsandiego.com BCC'd for audit purposes.

What's Next

  • EventBridge Scheduling — Deploy a CloudWatch Events rule to trigger report generation on a weekly