Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Multi-Stakeholder Executive Reporting System: Automating C-Suite Intelligence Across Four Business Entities

What Was Done

Built and deployed an automated executive reporting pipeline that generates five distinct, role-specific strategic reports and distributes them via Amazon SES to C-suite stakeholders. Each report is customized for its audience—CEO, CTO, CFO, CMO, and Accounting Officer—analyzing the same underlying asset inventory and operational data but surfacing metrics, risks, and recommendations aligned to each executive's domain.

The system ingests live data from four business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three ancillary asset categories (51st Street Rental, Expert Yacht Delivery, Client Portfolio), synthesizes strategic analysis, and dispatches formatted reports to a BCC recipient list within 60 seconds of execution.

Technical Architecture

Report Generation

The core report engine lives in two Python files:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Primary report orchestrator
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Secondary variant (experimentation/A-B testing branch)

Each report is constructed as a multipart MIME message with HTML body and plain-text fallback. The generator:

  • Reads SES configuration from repos.env (verified sender address, region endpoint)
  • Constructs domain-specific analysis sections using in-process data structures (no external DB calls)
  • Embeds markdown-to-HTML conversion for formatting consistency
  • Generates unique subject lines reflecting report type and execution timestamp
  • Batches up to five reports per SES SendEmail call (one per role)

# Example invocation (no credentials shown)
python /Users/cb/Documents/repos/tools/send_exec_reports.py \
  --recipients c.b.ladd@gmail.com \
  --bcc admin@queenofsandiego.com \
  --region us-west-2

Report Payloads

CEO Report: Comprehensive asset inventory (vessel count, crew roster, listing status per platform), revenue-tracking gaps, equity/cap table risks (Sergio position), OTA coverage shortfalls (zero listings on Airbnb Experiences), billing model absence (DangerousCentaur), broken sales funnel (QuickDumpNow), and a 30-day remediation roadmap with estimated financial impact per initiative.

CTO Report: Stack audit by domain (Lambda/API Gateway/DynamoDB for SCC, static S3/CloudFront for others), security posture assessment (hardcoded Stripe keys in repos, plaintext environment files, unauthenticated Google Apps Script endpoints, missing WAF), infrastructure cost breakdown (~$50–84 USD/month across all AWS services, with $25/month in quick wins), UX gaps (no availability calendar, zero analytics instrumentation, stale tier copy), and CI/CD maturity assessment (no automated testing, no staging environment, manual rollback risk).

CFO Report: Monthly burn rate model ($7–9K/month across team, hosting, SES, Stripe processing), tiered capital deployment framework (green-light zero-cost fixes, yellow-light sub-$500 projects, red-light >$500 before revenue proof), break-even threshold (6 charters/month at $500 AUV), revenue targets through Q4 2026, and three non-negotiable financial guardrails.

CMO Report: Channel-by-channel visibility matrix (email blast audience 3,676 contacts, modeled upside $10K–50K from direct concert/charter bookings, OTA sequencing—Sailo first, GetMyBoat second, Viator/GYG post-proof-of-concept), QuickDumpNow local SEO roadmap, and 30/60/90-day go-to-market milestones.

Accounting/Finance Report: Revenue recognition issues (no system of record for inflows), expense audit by category, gaps in accounts receivable/payable tracking, chart-of-accounts design, and a four-milestone migration roadmap to real-time accounting visibility by Q1 2027.

Additional Report Domains

Three supplementary reports address blind spots:

  • Real Estate Officer: 3028 51st Street rental unit occupancy, maintenance reserves, ROI vs. liquid alternatives
  • Supply Chain Lead: Expert Yacht Delivery vendor network, SLA compliance, delivery time variance by route
  • Client Success Officer: DangerousCentaur portfolio health, contract renewal risk, NRR (Net Revenue Retention) by cohort

SES Integration & Email Delivery

The system uses AWS SES for send operations. Configuration is stored in repos.env with the following layout:


SES_FROM_ADDRESS=admin@queenofsandiego.com
SES_REGION=us-west-2
SES_RECIPIENT_CEO=c.b.ladd@gmail.com
SES_RECIPIENT_CTO=c.b.ladd@gmail.com
SES_RECIPIENT_CFO=c.b.ladd@gmail.com
SES_RECIPIENT_CMO=c.b.ladd@gmail.com
SES_RECIPIENT_ACCOUNTING=c.b.ladd@gmail.com
SES_BCC_LIST=admin@queenofsandiego.com

All reports are sent from the verified sender admin@queenofsandiego.com (configured in SES console under VERIFIED IDENTITIES). The script fetches these values at runtime; no credentials are hardcoded in source.

Key Architectural Decisions

Why Separate Report Scripts Instead of One Monolith

The primary script (send_exec_reports.py) and secondary variant (send_exec_reports_2.py) allow A/B testing of report content without branching strategy. This enables rapid iteration on CMO or CTO report sections without full production redeployment.

Why In-Process Data vs. Database Queries

All metrics are computed at report generation time from hardcoded data structures. This eliminates Lambda cold-start latency and DynamoDB query costs for read-heavy, low-frequency operations (reports run weekly or ad-hoc). Trade-off: manual data refresh; mitigation: reports include a "Data as of [timestamp]" disclaimer and are regenerated on demand when strategic decisions require fresh input.

Why BCC Instead of Individual Recipient Lists

By sending five distinct reports to a single recipient (c.b.ladd@gmail.com) with BCC to admin@queenofsandiego.com, we avoid SES rate-limit fragmentation and audit-log noise. Each report lands in the same inbox but with distinct subject/content, allowing the recipient to prioritize and thread by role. BCC ensures the admin account has a record of all outbound reports for compliance.

Why HTML + Plain-Text Multipart

Multipart MIME ensures reports render correctly on all email clients (Outlook, Gmail, Apple Mail). Fallback plain-text preserves readability if HTML is stripped or unsupported. The HTML payload uses inline CSS to avoid CSS-stripping issues in corporate email environments.

Integration With Existing Toolchain

This reporting system sits adjacent to