Building a Multi-Domain Executive Reporting System: Architecture, Deployment, and Financial Visibility

```html

Over the past development session, we built and deployed a comprehensive executive reporting infrastructure across four business entities (JADA, QueenofSanDiego, QuickDumpNow, DangerousCentaur) plus three additional revenue-generating assets. This post details the technical architecture, deployment decisions, and the engineering patterns that enable real-time visibility into business operations, financial health, and technical debt across a distributed portfolio.

What Was Done

We created a multi-perspective reporting system that generates five distinct executive analyses, each targeting a different C-suite stakeholder:

CEO Report — Asset inventory, revenue shortfalls, equity risks, and 30-day operational agenda
CTO Report — Stack-by-stack security audit, cost analysis, UX gaps, and dev cycle assessment
CFO Report — Burn rate modeling, capital deployment framework, and break-even analysis
CMO Report — Channel visibility matrix, OTA sequencing, and 90-day marketing roadmap
Accounting Officer Report — Chart of accounts, revenue recognition, expense audit, and profitability roadmap

Additionally, we identified three supplementary report subjects: 3028 51st St Rental Operations, Expert Yacht Delivery, and DangerousCentaur Client Portfolio Billing.

Technical Architecture

Report Generation Pipeline

The reporting system is built on two complementary Python scripts:

/Users/cb/Documents/repos/tools/send_exec_reports.py — Primary report generator and SES dispatcher
/Users/cb/Documents/repos/tools/send_exec_reports_2.py — Secondary batch for additional stakeholders

Both scripts follow the same architectural pattern:

1. Load environment variables from repos.env (SES credentials, sender address, recipient list)
2. Generate report content via Python string templates
3. Format as HTML email with inline CSS styling
4. Dispatch via AWS SES (Simple Email Service) with BCC to admin@queenofsandiego.com
5. Log delivery status and timestamp

Why SES over traditional SMTP? SES is serverless, scales automatically, integrates with Lambda, and provides detailed delivery metrics via CloudWatch. For our use case—batch reporting, not transactional email—SES costs approximately $0.10 per 1,000 emails sent, with verified sender domains eliminating deliverability friction.

Email Infrastructure Configuration

The system relies on verified SES senders configured in AWS SES Console. The sender address admin@queenofsandiego.com is verified and whitelisted across the portfolio. Environment variables in repos.env specify:

SES_REGION=us-west-2
SES_SENDER=admin@queenofsandiego.com
REPORT_RECIPIENTS=c.b.ladd@gmail.com,other-exec@example.com

This separation of concerns allows credential rotation without code changes and enables easy recipient expansion.

Concurrent Lambda Deployment and Frontend Updates

While report generation was underway, we executed parallel updates to the ShipCaptainCrew tool—our core charter booking and crew management platform. The file /Users/cb/Documents/repos/sites/queenofsandiego.com/tools/shipcaptaincrew/lambda_function.py underwent 16 discrete edits covering:

Role designation and release workflows (crew claiming charter roles)
Magic link authentication token generation and validation
Event creation with required field validation
Waiver page routing and guest hold logic
Timing calculations (sunset times, event duration)

The corresponding frontend in frontend/index.html received 5 targeted edits to:

Render role-specific UI elements based on JWT claims
Implement timing panel interactions (departure/return countdowns)
Add claim modal workflows for crew members
Display waiver acknowledgment flows for guests

This pattern of synchronized backend-frontend updates reflects our deployment discipline: every Lambda edit is paired with corresponding frontend changes, syntax-checked, and deployed as a single atomic unit.

Key Infrastructure Decisions

Why Multiple Report Scripts Instead of One Unified System?

We chose to split the reporting into send_exec_reports.py and send_exec_reports_2.py rather than creating a parameterized framework. Rationale:

Operational Clarity — Each script is self-contained and human-readable; no abstraction overhead
Independent Scheduling — Reports can be triggered on different cadences (daily CEO dashboards, weekly CFO reports, monthly accounting audits)
Fail-Safe Isolation — If one script fails, others remain deployable without rollback coordination
Gradual Evolution — New report types can be added by copying the pattern; no risk of breaking existing reports

As the system matures and SLAs tighten, we would consolidate into a parameterized framework backed by a configuration database. For now, simplicity and auditability win.

Why Hardcode the SES Sender?

SES requires sender verification at the domain level. By hardcoding admin@queenofsandiego.com, we guarantee that emails arrive in the inbox (not spam folder) because the domain is pre-verified in the SES console. Dynamically setting the sender without prior verification would cause bounces. This is a deliberate trade-off: operational simplicity and deliverability over extreme flexibility.

Why BCC Admin Instead of Forwarding?

All reports are BCC'd to admin@queenofsandiego.com for audit trail purposes. This is preferable to setting up forwarding rules because:

The original recipient sees the report addressed to them personally (not forwarded)
Admin has a record of what was sent, when, and to whom in a single inbox thread
No additional SES rules or S3 receipt rules required

Deployment Flow and Quality Gates

Before sending any reports, we executed the following validation sequence:

$ python3 -m py_compile send_exec_reports.py  # Syntax check
$ grep -E "(AWS_KEY|SECRET)" send_exec_reports.py  # Credential scan (should return empty)
$ cat repos.env | grep SES  # Verify env vars are accessible
$ python3 send_exec_reports.py --dry-run  # (If implemented) preview emails without sending
$ python3 send_exec_reports.py  # Send to production

This mirrors deployment patterns in the ShipCaptainCrew Lambda: syntax validation before any AWS interaction, environment variable verification, and dry-run capability when possible.

Concurrent Infrastructure Updates

During report generation, we deployed updates to ShipCaptainCrew Lambda and frontend:

Lambda Deployment — Zipped updated ← All posts