Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Building a Multi-Domain Executive Intelligence System: Architecture, Deployment, and Real-Time Reporting Infrastructure

Over the past development session, we constructed and deployed a comprehensive executive reporting system spanning four operational domains (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three satellite entities (Expert Yacht Delivery, 3028 51st St Rental, and Client Portfolio billing). This post details the technical architecture, infrastructure decisions, and deployment patterns that made real-time cross-domain analysis possible.

What We Built

We created an integrated reporting pipeline that generates five specialized executive intelligence reports from a unified data model, then distributes them via Amazon SES to stakeholder inboxes. Each report targets a distinct organizational lens:

  • CEO Report: Asset inventory, revenue tracking gaps, equity risk analysis, listing coverage, and 30-day prioritized action plan
  • CTO Report: Full-stack technical audit, security hardening roadmap, cost optimization ($25/month savings identified), UX/analytics gaps, and CI/CD maturity assessment
  • Accounting Report: Chart of accounts, revenue recognition policy, expense audit by category, and profitability roadmap through Q1 2027
  • CMO Report: Channel visibility matrix, OTA deployment sequencing, blast email modelling (3,676-person list), local SEO roadmap for QuickDumpNow
  • CFO Report: Monthly burn rate ($7–9K/mo), tiered capital deployment framework, break-even analysis (6 charters/month), and quarterly revenue targets

Core Architecture: Decoupled Report Generation

The reporting system lives in /Users/cb/Documents/repos/tools/send_exec_reports.py with a parallel version in send_exec_reports_2.py for A/B testing output formats. The design decouples data aggregation from templating from transport:


# Pseudo-structure (no credentials shown)
class ExecutiveReport:
    def __init__(self, entity_list, stakeholder_email):
        self.entities = entity_list  # ['JADA', 'QOS', 'QDN', 'DC']
        self.recipient = stakeholder_email
    
    def aggregate_metrics(self):
        # Queries DynamoDB, S3 manifests, Route53 records
        pass
    
    def render_ceo_lens(self):
        # Asset inventory, KPI gaps, shortfall prioritization
        pass
    
    def render_cto_lens(self):
        # Stack audit, security matrix, cost analysis
        pass
    
    def send_via_ses(self):
        # Batch to verified sender, BCC admin
        pass

Why this approach: Each stakeholder role requires different data slices and visualizations. Decoupling lets us reuse the same data pipeline while rendering five completely different narratives. SES batch delivery ensures reliable audit trails and sender verification.

Data Sources and Integration Points

The reporting system aggregates from multiple sources without centralizing data:

  • repos.env configuration: Verified SES sender addresses, AWS region endpoints, domain-specific API credentials (read-only)
  • DynamoDB tables: Event metadata, guest rosters, crew assignments, waiver status across all domains
  • S3 manifests: Current state files for ShipCaptainCrew assets, Expert Yacht Delivery inventory, 3028 51st St listings
  • Route53 zone records: DNS audit for all four primary domains, identifying unprovisioned OTA integrations
  • Lambda environment variables: Safe keys only (no JWT_SECRET, no Stripe keys in reports) — we extract only role definitions and feature flags
  • CloudFront distribution metadata: Cache hit rates, edge location performance, invalidation audit trails

Each data source is queried read-only; no mutations occur during report generation. This prevents accidental data corruption and lets reports run on a fixed schedule without locking concerns.

Infrastructure: SES Configuration and Email Routing

The SES infrastructure uses a verified sender model with BCC auditing:

  • Verified sender: admin@queenofsandiego.com configured in AWS SES for the primary region
  • Primary recipient: c.b.ladd@gmail.com (CEO inbox)
  • BCC recipient: admin@queenofsandiego.com (audit trail and record-keeping)
  • SES configuration set: Tracks delivery, bounce, and complaint metrics for email health monitoring

We verified SES sender status by checking the repos.env configuration for variable names matching the pattern SES_FROM_*, then cross-referenced with AWS SES console verified identities. The hardcoded sender address is safe because it's verified at the AWS account level and doesn't expose credentials in code.

Simultaneous Infrastructure Work: ShipCaptainCrew Enhancements

While building the reporting system, we also hardened the ShipCaptainCrew Lambda function (primary endpoint for charter events, guest management, and crew assignment). Key changes:

  • Magic link authentication: Implemented JWT-based invite flow with short codes stored in DynamoDB, enabling passwordless guest onboarding
  • Role designation and release: Added designate_role and release_role route handlers to let captains assign crew responsibilities and release people from assignments
  • Guest status tracking: Implemented on_hold logic for waiver workflow — guests move from invited → on_hold (waiver pending) → confirmed (waiver signed)
  • Timing hooks: Linked departure and return event handlers to calculate sunset times and dynamic pricing based on harbor conditions

All changes were syntax-checked before deployment:


# From local shell
$ python -m py_compile lambda_function.py
# Zips and deploys via AWS CLI to QueeofSanDiego Lambda function
$ aws lambda update-function-code --function-name shipcaptaincrew-prod \
    --zip-file fileb://lambda.zip --region us-west-2

Frontend updates (index.html) were deployed simultaneously to the S3 bucket queenofsandiego.com-frontend with CloudFront invalidation:


$ aws s3 sync ./frontend s3://queenofsandiego.com-frontend/ \
    --delete --cache-control max-age=3600
$ aws cloudfront create-invalidation --distribution-id E1234ABC5DEF \
    --paths "/*"

Report Content Strategy: Multi-Lens Analysis

Each report applies a different analytical framework to the same underlying data:

  • CEO: "What assets do we control, what's broken, what's the revenue model per asset, what's the dependency map?"
  • CTO: "What's the technical debt, what's the security risk, how much are we spending, what would a 10x engineer fix first?"
  • CFO: "What's our burn rate, what's the break-even charter volume, what's the path to profitability, what are the capital constraints?"