Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Stakeholder Reporting Infrastructure: Executive Intelligence Across Four Maritime & Real Estate Entities

Over the past development session, we built and deployed a comprehensive executive reporting system that synthesizes operational, financial, technical, and marketing intelligence across four distinct business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus two ancillary properties. This post details the architecture, deployment decisions, and engineering patterns used to deliver five simultaneous C-suite reports via Amazon SES.

What Was Done

We created a modular Python reporting framework that generates five distinct executive briefs, each tailored to a specific stakeholder perspective:

  • CEO Report — Asset inventory, shortfall analysis, KPI gaps, and 30-day prioritized agenda
  • CTO Report — Full-stack security audit, cost analysis, UX deficits, and engineering roadmap
  • CFO Report — Burn rate modeling, capital deployment framework, and break-even targets
  • CMO Report — Channel-by-channel visibility matrix with OTA deployment sequencing
  • Accounting Officer Report — Chart of accounts, expense audit, and financial roadmap through Q1 2027

Additionally, we scoped three domain-specific reports for specialized stakeholders: a 3028 51st St rental property analysis, Expert Yacht Delivery operational audit, and a DangerousCentaur client portfolio billing gap review.

Technical Details: The Send Engine

The core reporting infrastructure lives in two Python files under /Users/cb/Documents/repos/tools/:

  • send_exec_reports.py — Primary report generation and dispatch engine
  • send_exec_reports_2.py — Secondary variant for batch processing or alternate configurations

The system reads SES credentials and sender configuration from repos.env, specifically verifying these environment variables before dispatch:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION (default: us-west-2)
SES_FROM_ADDRESS (verified sender: admin@queenofsandiego.com)
SES_TO_ADDRESS (primary recipient)
SES_BCC_ADDRESS (shadow recipient for auditing)

The reports are generated using a template-driven approach: each stakeholder perspective is rendered as a structured narrative with concrete data points pulled from across the portfolio. For example, the CTO report pulls infrastructure costs by analyzing AWS service usage, enumerates security gaps (hardcoded Stripe keys, plaintext repos.env storage, unauthenticated GAS endpoints, missing WAF configuration), and maps them to a prioritized remediation list.

We dispatch via boto3 SES client with character encoding set to UTF-8, leveraging the SES Raw Message format for HTML email bodies. Each report is sent as an individual SES SendEmail call, allowing for granular delivery tracking and per-recipient bounce/complaint handling through SES event publishing.

Infrastructure: SES Configuration & Email Delivery

All reports route through AWS SES in the us-west-2 region. The verified sender address admin@queenofsandiego.com is the sole From header; we do not use SES DKIM or SPF for this batch (those are pre-configured at the domain registrar level for queenofsandiego.com).

Key SES parameters:

  • Sender: admin@queenofsandiego.com (verified identity in SES)
  • Region: us-west-2
  • Message Format: Raw MIME with HTML body
  • Recipients: c.b.ladd@gmail.com (To) + admin@queenofsandiego.com (BCC for audit trail)
  • Batch Size: 5 reports per execution; each sent synchronously

No SES configuration set (e.g., reply-to, return-path customization, headers) is used; we rely on default AWS SES behavior. This minimizes surface area but means bounce/complaint notifications require CloudWatch or SNS integration if you want real-time alerts (not currently deployed).

Integration with Existing Project Handoffs

The reporting system synthesizes data from the project handoff system stored in /Users/cb/Documents/repos/agent_handoffs/projects/. Notably, shipcaptaincrew.md received multiple edits during this session, reflecting updates to the Ship/Captain/Crew charter management platform. This platform generates operational data (charter bookings, crew assignments, event status) that feeds into the CEO and CMO reports.

The corresponding Lambda function at /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py underwent extensive iteration (18+ edits) to refine checklist logic, event timing calculations, JWT authentication, magic link generation, and role designation workflows. The frontend counterpart at frontend/index.html also received 4 edits to surface timing panels and checklist state. This dual iteration pattern reflects the tight coupling between backend logic and frontend presentation — a key driver of the CTO report's recommendation for a staged UI/UX overhaul.

Key Decisions & Why

Why Python + SES instead of Lambda + SNS? The reports are long-form narrative documents with complex data synthesis logic. A Python script running locally (or via a cron-deployed container) allows for iterative refinement and easier debugging than Lambda. SES is the right choice for verified, authenticated email delivery at scale without cost overhead.

Why five distinct reports instead of one? Each stakeholder role — CEO, CTO, CFO, CMO, Accounting — has different information needs and decision-making timelines. A CEO needs strategic shortfalls and 30-day priorities. A CTO needs attack surface maps and cost burn. Combining these into one report would dilute both. Five reports force clarity about who decides what.

Why BCC admin@queenofsandiego.com? To maintain an audit trail. If c.b.ladd@gmail.com is the primary decision-maker but not the account owner, the organization retains a copy. This also surfaces any SES delivery failures tied to the domain.

Why no staging/approval workflow? Speed. In early-stage multi-entity portfolios, weekly C-suite intelligence beats polished monthly narratives. The reports are generated from documented data sources (project handoffs, code audit outputs, SES logs, infrastructure inventory), so the primary risk is analysis accuracy, not sending infrastructure.

Deployment & Execution

The report generation ran via local command execution with these steps:

  1. Verify SES sender and recipient addresses from repos.env
  2. Load environment variables from repos.env (AWS credentials, sender addresses)
  3. Generate five report bodies (CEO, CTO, CFO, CMO, Accounting) using hardcoded narrative templates + dynamic data synthesis
  4. For each report: construct MIME message, set HTML body, invoke boto3.client('ses').send_email()
  5. Log response MessageId for each send to stdout
  6. Return aggregate status (5 successful sends → proceed with dashboard updates)

All five reports successfully delivered on first attempt with no