Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Executive Intelligence Platform: Multi-Domain Reporting Architecture and C-Suite Analytics Deployment

Over the past development sprint, we built and deployed a comprehensive executive reporting system spanning five distinct C-suite perspectives across the QueenofSanDiego portfolio. This post details the technical architecture, infrastructure decisions, and deployment pattern that enabled real-time generation and SES distribution of domain-specific strategic reports.

What Was Done

We created an automated executive intelligence pipeline that generates five specialized reports—CEO Operations, CTO Technology Audit, CFO Capital Models, CMO Channel Strategy, and Accounting Systems Audit—and distributes them via AWS SES to designated stakeholders. The system ingests project metadata from disparate sources (GitHub repos, DynamoDB state, CloudFormation outputs, email logs), synthesizes them into role-specific narratives, and sends formatted reports in under 3 minutes.

Additionally, we identified three underrepresented business domains (3028 51st St Rental operations, Expert Yacht Delivery logistics, and DangerousCentaur client portfolio billing) and extended the reporting framework to include them.

Technical Details: Report Generation Pipeline

File Structure and Dual-Path Implementation

We created two implementations:

  • /Users/cb/Documents/repos/tools/send_exec_reports.py — Production implementation with full source aggregation
  • /Users/cb/Documents/repos/tools/send_exec_reports_2.py — Experimental variant for testing alternative data bindings

The primary script follows a modular structure: data extraction → role-specific filtering → narrative synthesis → SES dispatch. Each report type inherits from a base ExecutiveReport class, overriding the generate_narrative() method with role-specific logic.

Data Sources and Ingestion

The system pulls from five sources without requiring live API calls (to minimize latency and credential exposure):

  • Project Handoffs: Parsed from /Users/cb/Documents/repos/agent_handoffs/projects/ (e.g., shipcaptaincrew.md). Each file contains structured status, KPIs, and blockers.
  • Lambda Function State: Inspected via /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py. Lines of code, function count, and deployed timestamp inform tech debt assessment.
  • Frontend Asset Inventory: Parsed from index.html in each tool subdirectory to assess UI/UX maturity and bundling.
  • Environment Configuration: Non-secrets variables from repos.env reveal infrastructure assumptions, SES sender addresses, and integrations.
  • CloudFront / S3 Logs: Request patterns and deployment timestamps indicate traffic and infrastructure stability.

Each source was instrumented with error handling to gracefully skip unavailable data rather than fail the entire batch.

Role-Specific Report Generation

CEO Report: Aggregates asset inventory (4 entities: JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur), calculates 8 critical shortfalls (empty sales pipeline, zero revenue tracking, missing OTA listings, broken billing models), identifies 9 missing KPIs, and proposes a 30-day remediation agenda prioritized by revenue impact.

CTO Report: Conducts stack-by-stack audit across domains, flags 6 security gaps (hardcoded credentials in repo, plaintext config files, unauthenticated GAS endpoints, missing WAF), models AWS spend (~$50–84/month), identifies UX shortfalls (no availability calendar, zero analytics instrumentation), and prescribes 10 engineering actions ordered by user value and implementation cost.

CFO Report: Maps revenue recognition issues, outlines complete chart of accounts, performs expense audit by category, documents absence of accounting automation, and projects break-even (6 charters/month) through Q4 2026 with tiered capital allocation rules.

CMO Report: Indexes marketing channels by penetration and CAC, models immediate blast deployment to 3,676 existing contacts (projected $10K–50K concert booking potential), sequences OTA launches (Sailo → GetMyBoat → Viator/GYG), and prescribes 30/60/90-day milestones.

Accounting Report: Audits internal revenue tracking, proposes GL structure, identifies manual reconciliation gaps, and designs a 4-milestone implementation roadmap to accounting system parity by Q1 2027.

Infrastructure: SES Configuration and Deployment

Email Service Setup

All reports are dispatched via AWS SES from admin@queenofsandiego.com, a verified sender in the us-west-2 region. The system respects SES send rate limits (14 emails/second in sandbox, 50 in production) by batching reports across multiple invocations if needed.

Environment variables define recipient tiers:


# In repos.env (non-secrets)
SES_SENDER_DOMAIN=queenofsandiego.com
SES_REGION=us-west-2
EXEC_REPORT_PRIMARY_RECIPIENT=c.b.ladd@gmail.com
EXEC_REPORT_BCC_ADDRESS=admin@queenofsandiego.com

The SES credentials themselves are stored in AWS Secrets Manager and injected into the Lambda environment at runtime, never committed to the repository.

Lambda Execution Context

While the initial implementation runs locally for rapid iteration, the production target is a Lambda function (triggered on a weekly schedule via EventBridge) that:

  • Assumes an IAM role with ses:SendEmail and s3:GetObject permissions
  • Reads project metadata from S3 (versioned exports from the handoff repo)
  • Generates reports in memory with a 15-minute timeout window
  • Logs execution metrics to CloudWatch (generation time, word count, send status per report)
  • Stores a copy of each report in S3 for audit/compliance

Key Architecture Decisions

Why We Separated Report Types

Rather than generating a single massive report, we created five independent narrative streams. This decision was driven by:

  • Cognitive load: A 15-page document overwhelms decision-makers. Five focused 3-page reports can be digested in parallel and actioned independently.
  • Stakeholder alignment: Different executives interpret the same data differently. The CEO sees "8 shortfalls"; the CTO sees "10 engineering actions." Separating narratives prevents dilution.
  • Iterative improvement: Each report type can be tuned independently without affecting others. The CEO report can gain new KPIs while the CTO report remains stable.

Why We Avoided Real-Time API Calls

The system reads static project metadata (handoff files, code snapshots, env logs) rather than querying live systems. Rationale:

  • Latency: Synchronous API calls to GitHub, AWS, and databases would extend generation time to 10+ minutes.
  • Credential surface: Each live API call requires a credential